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ABSTRACT 


Any  military  operation,  no  matter  how  large  or  small  requires  some  level  of 
planning.  Planning  has  become  more  complicated,  requiring  more  interactions  across 
geographical,  functional,  and  organizational  boundaries  in  a  more  compressed 
command  and  control  decision  cycle.  For  ships  at  sea,  conducting  planning  with 
other  units,  at  sea  or  on  shore,  is  constrained  by  the  availability  of  communications 
bandwidth  and  limitations  of  the  tools  used  for  real-time  interactions.  Emerging  tools 
such  as  audio  and  video  conferencing  and  shared  whiteboard,  enable  real  time 
collaboration  among  dispersed  forces,  however,  these  tools  are  bandwidth  “greedy,” 
requiring  more  than  is  currently  available  on  many  ships.  In  an  effort  to  determine 
what  amount  of  bandwidth  a  ship  needs,  this  thesis  used  simulation  and  modeling  to 
experiment  with  combinations  of  bandwidth,  collaboration  tools  and  the  number  of 
planners. 

In  general,  a  bandwidth  of  128  kbps  enables  two  ships  to  conduct  a  video  and 
audio  session.  Using  multicast  network  delivery,  256  kbps  enables  a  ship  to 
collaborate  with  five  other  sites,  and  at  384  kbps,  a  ship  can  conduct  a  whiteboard 
with  video  and  audio  with  up  to  eight  other  sites. 
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EXECUTIVE  SUMMARY 


Planning  is  the  act  of  preparing  for  future  events.  Any  military  operation,  no 
matter  how  large  or  small,  length  of  anticipated  duration,  or  how  much  time  is 
available  to  prepare,  requires  some  level  of  planning.  In  today’s  environment  of 
increased  operational  tempo,  more  widely  dispersed  forces,  and  operations  in  joint  or 
multinational  coalition  force  structures,  planning  has  become  more  comphcated. 
Planning  requires  more  interactions  across  geographical,  functional,  and 
organizational  boundaries  and  in  a  more  compressed  timeframe  in  order  to  keep  our 
coriimarid  and  control  decision  cycle  faster  than  our  adversaries.  For  ships  at  sea, 
conducting  planning  with  other  units,  at  sea  or  on  shore,  is  constrained  by  the 
availability  of  communications  bandwidth  and  limitations  of  the  tools  used  for  real¬ 
time  interactions. 

Emerging  products,  such  as  audio  and  desktop  video  conferencing,  and  shared 
whiteboard,  enable  geographically  dispersed  people  to  collaborate  in  real-time.  Used 
at  sea,  these  tools  provide  the  ability  for  planners  to  share  information  in  a  •v\ide 
variety  of  formats,  in  real-time  with  their  counterparts  on  other  ships  or  ashore. 
However,  these  tools  are  bandwidth  “greedy”  and  require  more  bandwidth  than  is 
currently  available  on  many  ships.  Any  implementation  of  these  tools  involves  a 
trade-off  decision  between  the  cost  of  the  resource,  bandwidth,  and  the  amount  of 
capability  desired,  such  as  audio,  video,  or  whiteboard. 

How  much  bandwidth  does  an  amphibious  ship  need  in  order  to  perform 
collaborative  planning?  The  thesis  seeks  to  provide  some  insight  into  this  question 
through  the  use  of  a  high-level  simulation  model  built  using  a  commercial  off-the-shelf 
product  called  Extend.  Over  170  model  runs  were  executed  with  various 
combinations  of  the  three  collaboration  tool  types,  the  amount  of  bandwidth,  the 
number  of  planners  involved  in  a  planning  session,  and  the  type  of  network  deUvery 
method  used.  The  results  of  these  runs  are  presented  from  three  different  aspects,  by 
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required  collaboration  capabilities,  by  bandwidth,  or  by  the  number  of  other  planners 
that  can  be  involved,  as  follows: 

•  Minimum  collaboration  capabilty  required  by  the  ship.  If,  at  a  minimum,  a  ship 
must  be  able  to  conduct  a  video  and  audio  session  with  one  other  ship,  than  at 
least  128  kbps  must  be  available  to  each  ship.  To  conduct  a  whiteboard  with 
audio  session,  at  least  256  kbps  must  be  available.  Whiteboard  with  video  and 
audio  requires  384  kbps. 

•  Bandwidth  is  limited.  If  a  ship  only  has  128  kbps  available,  then  the  ship  will  only 
be  able  to  conduct  a  video  and  audio  session  with  one  other  ship.  At  256  kbps,  a 
ship  can  collaborate  via  a  video  and  audio  session  or  a  whiteboard  with  audio 
session  with  up  to  two  other  sites.  At  384  kbps,  using  multicast  delivery,  a  ship 
will  be  able  to  engage  up  to  eight  other  sites  in  a  whiteboard  with  audio  session. 

•  Number  of  planners  required  in  a  collaboration  session.  To  collaborate  with  one 
other  planner  a  ship  requires  at  least  128  kbps  and  a  session  with  two  other 
planners,  at  least  256  kbps.  To  collaborate  with  five  to  eight  other  planners,  at 
least  384  kbps  must  be  available  at  the  ship  and  multicast  network  delivery  must 
be  used  to  ease  the  bandwidth  congestion  at  the  ship. 

To  ensure  flexibility  and  adaptability  to  any  planning  situations  a  ship  may  be 
engaged  in,  an  optimum  mix  might  be  to  provide  at  least  256  kbps  bandwidth  and  use 
multicast  network  delivery,  so  the  ship  can  access  some  combination  of  the  three 
collaboration  capabilities  provided  by  the  tools  with  up  to  five  planning  counterparts. 
Without  multicast  delivery,  at  least  384  kbps  will  be  required  for  three  ships  to  engage 
in  a  collaborative  planning. 
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L  INTRODUCTION 


A.  OVERVIEW 

An  amphibious  operation  is  an  attack  launched  from  the  sea  by  naval  and  landing 
forces  embarked  in  ships  or  craft  landing  on  a  hostile  shore  (Joint  Pub  3-02).  The  amount 
of  communications  support  required  for  such  an  operation  exceeds  that  of  any  type  of 
naval  warfare  (Kim  and  Muehldorf).  Planning  for  a  landing  is  also  complex  due  to  the 
involvement  of  all  types  of  ships,  aircraft,  weapons,  and  units  of  the  Navy  and  landing 
forces  and  the  geographic  dispersion  of  supporting  forces. 

Much  of  the  information  shared  and  analyzed  during  amphibious  landing  planning 
involves  the  use  of  maps,  charts,  and  imagery.  Ships  are  limited  in  the  ways  they  can 
interact  with  their  planning  partners  at  sea  or  ashore,  and  the  format  of  the  information 
does  not  lend  itself  to  unambiguous  discussion  over  voice  circuits  or  through  text 
messages.  Planners  left  to  work  independently  in  different  locations  on  the  same  plan  run 
the  risk  of  forming  separate  and  distinct  interpretations  of  that  plan  unless  efforts  are 
expended  to  keep  all  planners  in  synchrony. 

New  communications  capabilities  are  possible  with  the  use  of  collaboration  tools  such 
as  audio  and  video  conferencing  and  whiteboard  applications.  These  tools  can  provide  the 
means  for  an  Amphibious  Ready  Group  (ARG)  or  Amphibious  Task  Force  (ATF)  at  sea 
to  continue  to  conduct  planning  with  shore-based  or  other  ship  organizations  and  to  do  it 
in  real-time.  However,  these  tools  require  higher  bandwidths  than  currently  possessed  by 
amphibious  ships.  SHF  bandwidth  to  the  ARG  Flagship  (LHA/LPD)  can  range  from  256 
kbps  to  512  kbps,  but  the  other  ARG  ships  are  not  SHF-capable.  All  amphibious  ships  are 
UHF-capable,  which  can  range  from  2.4  kbps  to  9.6  kbps. 

Several  efforts  are  underway  to  increase  the  amoimt  of  bandwidth  on  these  ships,  and 
most  are  focused  on  point-to-point  or  Line  of  Sight  communications  for  use  between  two 
ships  or  a  ship  and  shore-based  unit.  Three  efforts  of  note  are  (CPG3,  Day): 
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•  Digital  Wideband  Transmission  System  (DWTS)  which  will  provide  UHF  LOS 
at  T1  (1.544  Mbps)  from  ship  to  ship  and  from  ship  to  shore  at  144  kbps,  288 
kbps  or  576  kbps. 

•  UHF  Medium  Data  Rate  (MDR)  which  will  provide  448  kbps. 

•  Hazeltine,  an  effort  to  provide  a  “network”  capability  among  three  ships  using 
radios  at  64  kbps. 

B.  OBJECTIVE 

The  purpose  of  this  thesis  is  to  determine  the  bandwidth  requirements  for  collaborative 
planning  by  amphibious  ships.  The  approach  taken  was  to  identify  characteristics  of  the 
tools  used  for  collaboration  (text  chat,  audio  and  video  conferencing,  whiteboard)  and 
simulate  the  use  of  these  tools  in  a  network  among  two  to  nine  planning  participants, 
varying  the  amount  of  available  bandwidth. 

C.  METHODOLOGY 

To  assess  the  impact  that  bandwidth  has  on  the  use  of  collaboration  tools,  a  network 
simulation  model  was  built  using  Extend,  by  Imagine  That,  Inc.  To  derive  the  parameters 
of  the  model,  current  information  about  collaboration  tools,  their  bandwidth  requirements 
and  the  planning  process  employed  by  Amphibious  Ready  Groups  (ARG)  was  obtained  by 
conducting  a  literature  review,  Internet  searches,  and  discussions  with  persormel  at 
SPAWAR  San  Diego,  COMPHIBGRU  THREE,  Amphibious  Warfare  School  Pacific,  and 
MITRE.  Various  combinations  of  the  parameter  settings  were  executed  and  the  model 
results  were  assessed  against  the  following  selected  measures  of  effectiveness:  the  average 
amount  of  time  for  text  chat,  audio,  video  and  whiteboard  data  to  travel  between 
participants.  Lengthy  travel  times  degrade  the  quality  of  audio  and  video  conferencing. 


D,  THESIS  ORGANIZATION 


Chapter  11  provides  an  overview  of  four  collaboration  tools,  text  chat,  audio 
conferencing,  video  conferencing,  and  whiteboard,  with  discussion  of  their  limitations  and 
bandwidth  requirements.  Chapter  HI  presents  backgroimd  on  the  ARG  planning  process, 
such  as  what  information  is  discussed  and  when,  who  is  involved,  and  where  planning 
occurs.  A  discussion  of  the  Extend  model  structure  and  specific  parameter  settings  are 
contained  in  Chapter  IV,  and  the  results  of  the  model  runs  are  presented  in  Chapter  V. 
Chapter  VI  will  provide  conclusions  and  recommendations  for  fiiture  work. 
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n.  COLLABORATION  TOOLS 


A.  OVERVIEW 

Collaboration  tools  began  to  emerge  in  the  early  1990’s  when  faster  PCs,  increased 
network  and  communications  bandwidth,  and  more-capable  digital  video  components 
brought  such  capabilities  into  the  realm  of  possibility  and  affordability  (Garland).  This 
chapter  will  highlight  a  few  collaboration  tools  that  provide  the  means  for  same-time, 
different-place  interactions  such  as  text  chat,  audio  conferencing,  whiteboard,  and  desktop 
video  conferencing.  Short  descriptions  of  each  tool,  applicable  standards,  general 
limitations,  and  the  bandwidth  required  will  be  presented.  The  intent  is  not  to  elaborate  on 
all  the  technical  details  associated  with  multimedia  products  and  processes  but  to  give  a 
feel  for  some  of  the  concepts  and  issues. 


B.  DEFINITIONS 

The  following  definitions  and  concepts  are  common  across  all  collaboration  tools  and 
impact  how  the  tools  are  implemented. 

1.  Collaboration 

The  Random  House  Unabridged  Dictionary,  Second  Edition,  1993,  defines 
collaboration  “to  work,  one  with  another;  cooperate.”  Cooperate  is  “to  work  or  act 
together  or  jointly  for  a  common  purpose  or  benefit.”  Collaboration  always  involves  some 
form  of  interaction  between  two  or  more  people  and  it  can  occur  at  any  time  or  at  any 
place.  “People  who  need  to  collaborate  can  be  in  the  same  team  or  unit,  different  parts  of 
an  organization,  and  in  different  organizations.  They  can  be  located  anywhere  on  the 
globe  and  in  any  time  zone,  but  still  require  the  ability  to  communicate  with  each  other, 
share  information  with  each  other,  and  coordinate  their  activities”  (DIICOE  MCSTWG). 
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2.  Multimedia 


As  defined  in  the  Dictionary  of  PC  Hardware  and  Data  Communications  Terms,  by 
O’Reilly  and  Associates,  1996,  multimedia  means  “Literally  ‘many  media’,  for  example, 
using  sound,  pictures,  and  text  to  (hopefully)  make  a  more  effective,  understandable,  or 
memorable  presentation  or  conference.” 

Multimedia  teleconferencing  is  a  combination  of  technology  and  applications  that 
allow  multiple  users  in  multiple  locations  to  interactively  share  data,  desktop  applications, 
and  live  video  simultaneously.  The  ability  to  share  materials  facilitates  communications, 
brainstorming,  decision  making,  and  problem  solving.  (IMTC) 

To  support  multimedia,  networks  must  provide  (O’Reilly): 

•  Scalable  bandwidth:  New  users  and  new  applications  require  connectivity  and 
the  network  must  support  ever-increasing  traflSc  loads. 

•  Consistent  Quality  of  Service  :  The  error  rate  (usually  due  to  dropped  packets), 
network  latency  (typically  less  than  400  ms,  round-trip),  and  network 
throughput  must  be  selectable  (according  to  the  needs  of  the  application)  and 
predictable. 

•  Multicast  routing,  to  efficiently  support  one-to-many-type  traffic. 


3.  Bandwidth 

In  general  terms,  bandwidth  has  come  to  mean  the  number  of  bits  per  second  (bps) 
that  can  be  transmitted  over  various  media  and  is  the  most  significant  limiting  factor  in 
communications.  There  are  two  broad  categories  of  communication  channels,  circuit- 
switched  and  packet-switched,  and  each  has  imphcations  for  multimedia  teleconferencing. 
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Circuit-switched  means  that  a  dedicated  path  is  formed  between  users  and  all  of 
the  available  bandwidth  of  that  chaimel  is  for  their  use  only;  it  is  not  shared  with  other 
users.  Collaboration  tools  get  the  bandwidth  they  require  and  the  delivery  of  information 
is  predictable,  without  delays.  If  the  full  amount  of  the  dedicated  bandwidth  is  not  needed 
during  the  connection,  it  is  in  effect  “wasted”  since  there  are  no  other  activities  on  the 
circuit  to  use  it.  When  the  communications  are  complete,  the  dedicated  channel  is 
disestablished  and  the  bandwidth  is  then  available  for  other  sessions.  Circuit-switched 
channels  are  primarily  for  point  to  point  communications,  and  conducting  a  collaborative 
session  with  greater  than  two  sites  requires  the  use  of  expensive  Multipoint  Conference 
Units  (MCU).  An  MCU  is  a  server  that  establishes  and  manages  real-time  distribution  of 
audio,  video,  and  document  sharing  among  several  sites.  Examples  of  circuit-switched 
channels  are  the  telephone  system  and  narrowband  Integrated  Services  Digital  Network 
(ISDN)  at  128  Kbps. 

Packet-switched  channels  share  their  total  bandwidth  among  all  the  users  who 
want  to  use  it.  A  user’s  information  is  broken  into  packets  and  each  is  labeled  with 
identification,  sequence  number,  and  destination.  The  packets  are  placed  onto  a  channel 
and  may  take  differing  routes  through  the  network  to  reach  their  destination,  some 
arriving  earlier  than  others.  The  time  required  for  the  transit  depends  upon  the  number  of 
users  on  the  channel  -  more  users  means  more  packets  competing  for  a  finite  amount  of 
bandwidth  resulting  in  longer  delays.  Collaboration  tools  such  as  audio  and  video  are 
sensitive  to  packets  that  arrive  out  of  order  or  experience  lengthy  delays  in  arrivals. 
Examples  of  packet-switched  channels  are  Local  Area  Networks,  such  as  10  Mbps  to  100 
Mbps  Ethernet,  and  Wide  Area  Networks,  such  as  Asynchronous  Transfer  Mode  (ATM) 
at  25  Mbps  to  2  Gbps  and  Frame  Relay  at  56  Kbps  to  1.544  Mbps. 

To  cope  with  bandwidth  limitations,  many  collaboration  applications  provide  the 
ability  for  users  to  adjust  several  parameters  of  their  audio  and  video  sessions. 
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4.  Compression  and  Decompression  (Codec) 

The  nature  of  audio  or  video  data  is  such  that  it  requires  large  amounts  of  bits  for 
accurate  representation.  To  conserve  the  amount  of  bandwidth  used  when  sending  audio 
or  video  data,  the  bits  that  represent  the  data  are  compressed  into  an  even  smaller  number 
of  bits  before  transmission  using  complex  algorithms  called  Codecs.  At  the  receiving  end, 
the  bits  are  decompressed  and  reconstructed  to  the  original  form. 

Compression  and  decompression  must  occur  at  extremely  fast  speeds  so  as  not  to 
interfere  with  the  real  time  interaction  of  a  collaborative  session.  Hardware  Codecs  are 
extremely  fast  at  performing  compression  algorithms,  but  they  are  also  very  expensive. 
Software  Codecs  are  easier  to  install  and  rely  on  the  workstation  CPU  for  processing 
power,  not  additional  hardware.  The  strain  the  software  Codec  puts  on  the  CPU  may 
limit  the  number  or  type  of  applications  a  user  may  execute  simultaneously  during  a 
session.  Some  Codec  implementations  are  a  mix  of  hardware  and  software  -  hardware  for 
compression,  which  is  more  computationally  intense  and  needs  to  be  done  quickly  without 
introducing  delay  and  software  for  decompression.  (CISCO,  Hudson) 

Many  algorithms  have  been  developed  for  implementing  compression  but  generally 
these  schemes  fall  into  one  of  two  types  (CISCO); 


•  Lossless.  A  compression  technique  that  creates  compressed  files  that 
decompress  into  exactly  the  same  file  as  the  original.  Lossless  compression  is 
typically  used  for  executables  (applications)  and  data  files  for  which  any 
change  in  digital  makeup  renders  the  fide  useless. 

•  Lossy.  This  type  of  compression,  used  primarily  on  still  image  and  video 
image  files,  creates  compressed  files  that  decompress  into  images  that  look 
similar  to  the  original  but  are  different  in  digital  makeup.  The  “loss”  is  that 
several  bits  of  the  image  are  no  longer  represented  but  the  human  eye  does  not 
detect  this  loss. 
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Interoperability  issues  frequently  arise  between  collaboration  products  since  many 
vendors  have  developed  their  own  proprietary  Codec  algorithms,  which  offer  a  wide  range 
of  performance,  quality,  and  cost  trade-offs. 

5.  Latency 

Real  time  interactive  apphcations  are  sensitive  to  accumulated  delay,  known  as 
latency.  A  network  contributes  to  latency  in  the  following  ways  (CISCO): 

•  Propagation  Delay.  The  length  of  time  that  information  takes  to  travel  the 
distance  of  the  line.  Propagation  delay  is  determined  by  the  speed  of  light  and 
is  not  affected  by  the  networking  technology  in  use. 

•  Transmission  Delay.  The  length  of  time  a  packet  takes  to  cross  a  given  media. 
Determined  by  the  speed  of  the  media  and  the  size  of  the  packet. 

•  Store  and  Forward  Delay.  The  length  of  time  an  internetworking  device  (a 
switch,  bridge,  or  router)  takes  to  send  a  packet  that  it  has  received. 

•  Processing  Delay.  The  time  required  by  an  internetworking  device  to  perform 
a  route  lookup,  change  headers,  and  other  switching  tasks.  In  some  cases,  the 
packet  may  have  to  be  manipulated  such  as  encapsulating  it  into  another  packet 
type. 

Variable  network  delays  can  cause  disruptions  in  audio  or  video  data,  called 
“jitter.”  A  common  technique  for  minimizing  jitter  is  to  buffer  the  arriving  data  at  the 
receiving  end  and  then  deliver  it  to  the  user  at  a  more  constant  rate. 
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6.  Quality  of  Service 

Two  measures  of  quality  of  service  are  the  reliability  of  delivery  across  a  network 
and  the  amount  of  delay  experienced.  Different  types  of  data  have  varying  degrees  of 
sensitivity  to  these  measures.  For  example,  transferring  data  files  requires  more  emphasis 
on  reliable  delivery  than  on  minimizing  delays  encountered  during  the  transfer.  It  is  more 
important  that  all  the  bits  arrive  than  whether  the  file  arrives  within  one  second  or  one 
minute  at  its  destination.  Table  2-1  summarizes  data  types  and  their  sensitivity  to  reliable 
delivery  and  delay. 


Data 

Voice 

Video 

Image 

Delay  Sensitive 

No 

Yes 

Yes 

No 

Reliability  Sensitive 

Yes 

No 

Yes/No 

Yes 

Table  2-1.  Data  Type  Sensitivities  (Rettinger). 


Delays  in  voice  transmissions  can  be  annoying  and  j&ustrating  to  people  involved 
in  a  discussion,  as  it  is  disruptive  to  the  flow.  Studies  have  shown  that  people  get  armoyed 
when  end-to-end  audio  delays  approach  400  milliseconds  (ms)  and  700  ms  to  800  ms  is 
beyond  tolerance.  Ideal  quality  of  service  for  a  one-way  audio  stream  is  considered  to  be 
less  than  45  ms  delay  plus  variance.  Telephone  networks  are  engineered  to  provide  less 
than  400  milliseconds  round-trip  latency  for  the  voice  signals  they  handle.  Voice  is  not 
sensitive  to  reliability  and  the  occasional  missing  sounds  or  syllables  can  be  recovered  by 
the  speaker  repeating  them  or  deduced  by  the  receiver  based  upon  content.  (Brown, 
Rettinger) 

Delays  in  receiving  video  can  cause  movements  to  appear  jumpy.  Uncompressed 
video  is  more  tolerant  of  lower  reliability  because  the  video  is  transmitted  a  frame  at  a  time 
and  any  fi-ame  sent  with  an  error  or  lost  enroute  will  be  replaced  by  a  newly  arriving 
fi-ame.  Compressed  video  is  already  reduced  in  the  amount  of  data  it  contains,  so  any 
corruption  or  loss  may  not  be  corrected  by  subsequent  frame  updates  as  the  redundancy 
has  been  removed.  This  possibility  is  corrected  by  sending  out  refi’esh  updates  -  a  series 
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of  frames  that  contain  all  the  video  data.  Tolerable  delay  for  video  can  be  up  to  95  ms 
delay  plus  variance.  (Brown,  Rettinger) 

If  given  a  choice  in  a  collaboration  session  as  to  whether  to  experience  audio 
delay  or  video  delay,  most  people  prefer  the  audio  to  be  delivered  as  close  to  real  time  as 
possible  and  will  endure  a  delay  in  the  video  even  though  it  will  be  out  of  sync  with  the 
audio  (Isaacs). 

7.  Standards 

To  guide  the  development  of  collaboration  tools  that  are  interoperable,  there  are 
several  standards  which  have  been  ratified  by  the  International  Telecommunications  Union 
(ITU).  The  T.120  series  addresses  real  time  data  conferencing  (audiographics)  standards 
that  allow  people  at  multiple  locations  to  conduct  normal  voice  conferences  and 
manipulate  still  images  such  as  documents,  spreadsheets,  color  graphics,  and  photographs. 
(IMTC) 

The  H.320  series  governs  the  basic  concepts  of  audio,  video,  and  graphical 
communications  by  specifying  requirements  for  processing  audio  and  video  information, 
providing  common  formats  for  inputs  and  outputs,  and  protocols  for  use  of 
communications  links  and  synchronnation  of  signals.  Specifically,  H.320  standards 
address  videoconferencing  over  circuit  switched  networks,  such  as  Integrated  Services 
Digital  Network  (ISDN).  H.323  extends  H.320  video  to  corporate  Intranets,  LANs  and 
other  packet-switched  networks,  such  as  the  Internet.  H.324  specifies  a  common  method 
for  sharing  video,  data,  and  voice  simultaneously  using  high-speed  modem  connections 
over  a  single  analog  line  telephone  line.  (IMTC) 

Since  collaboration  implies  communications  with  others,  using  products  that 
support  these  standards  is  the  single  biggest  factor  towards  being  able  to  conduct 
interoperable  collaboration  sessions.  All  parties  conducting  a  collaboration  session  must 
use  products  that  support  the  same  standards  or  the  session  can  not  be  conducted. 
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C.  TEXT  CHAT 


1.  Description 

Text  chat  is  a  method  by  which  two  or  more  people  can  converse  in  real  time  by 
typing  their  comments  on  their  computers,  which  are  connected  via  a  network.  Each 
person  sees  the  comments  t5^ed  by  the  other  conversation  participants.  What  you  type  is 
what  they  see.  Conversations  can  be  held  between  two  people  or  up  to  several  hundred 
people. 

Users  execute  text  chat  via  a  client  program  running  on  their  PC’s,  and  designated 
computers  on  the  network  run  server  programs.  These  servers  help  manage  and  transport 
the  messages  between  clients.  Each  conversation  is  called  a  channel  and  they  may  be 
public  (where  everyone  in  a  channel  can  see  what  you  type)  or  private  (messages  between 
only  two  people,  who  may  or  may  not  be  on  the  same  channel).  The  number  of  members 
participating  in  a  channel  is  dynamic  -  users  may  join  and  leave  at  any  time.  A  channel 
may  also  be  thought  of  as  a  named  group  of  one  or  more  users,  which  will  all  receive 
messages  addressed  to  that  channel. 


2.  Standards 

The  most  common  program  for  text  chat  is  Internet  Relay  Chat  (IRC),  which  has 
been  around  since  the  late  1980s  and  is  available  for  download  from  several  Internet  sites 
for  several  platforms:  UNIX,  Windows,  and  Macintosh.  IRC  consists  of  various  separate 
networks  (or  "nets")  of  IRC  servers  that  allow  users  to  connect  to  IRC.  One  of  the 
largest  nets  is  Efhet,  the  original  IRC  net,  which  often  has  more  than  32,000  people 
participating  at  once  and  has  more  than  12,000  channels,  each  devoted  to  a  different  topic 
[IRC].  Internet  Relay  Chat  is  the  Internet  Engineering  Task  Force  (IETF)  standard  for 
text-based  chat  (MITRE). 
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3.  Limitations 


People  can  think  and  talk  faster  than  they  can  type,  so  lengthy,  meaningful 
conversations  can  be  difficult  to  conduct  online.  There  is  a  maximum  user  message  length 
of  512  characters  (about  seven  typed  lines)  so  most  conversations  consist  of  short 
comments  and  requests  for  information  (IRC).  Obviously  this  tool  is  better  suited  to  share 
text-based  information,  not  graphics  or  imagery.  Text  chat  is  a  good  tool  for 
communications  across  a  network  when  other  tools  are  not  available,  such  as  the 
telephone,  video  or  audio  conferencing,  or  in  situations  when  bandwidth  is  constrained. 


4.  Bandwidth  Requirements 

Of  all  the  collaboration  tools,  text  chat  requires  the  least  amount  of  bandwidth. 
Messages  have  a  maximum  size  of  512  characters  or,  at  8  bits  per  character,  a  total  of 
4096  bits.  Increasing  the  number  of  participants  in  a  text  chat  session  does  not  really 
degrade  the  network  too  much  since  the  amount  of  information  seiit  at  a  time  is  so  small 
and  not  usually  sent  all  at  the  same  time.  For  example,  if  three  people  were  in  a  text  chat 
session,  the  worst  case  scenario  would  be  everyone  sending  a  message  at  the  same  time. 
A  user  sending  out  4096  bits  while  receiving  8192  bits  from  the  other  two  people  (4096 
bits  each)  would  have  a  total  of  12,288  bits  competing  for  bandwidth  at  her  workstation. 


D.  AUDIO  CONFERENCING 

1.  Description 

Audio  conferencing  has  traditionally  been  conducted  using  the  telephone  system 
for  performing  person-to-person  calls  or  conference  calls  of  greater  than  2  people.  Audio 
conferences  can  be  performed  across  networks  with  the  addition  of  a  microphone. 
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speakers,  a  sound  card,  and  a  compression-decompression  (Codec)  algorithm  to  a 
personal  computer. 

The  overall  process  is  to  digitize  your  voice’s  analog  signals,  compress  the  digital 
form,  transmit  it,  then  decompress  and  decode  the  digital  signal  at  the  receiving  end  -  all  in 
real  time.  Analog  to  digital  conversion  basically  consists  of  taking  a  series  of  samples  of 
the  analog  source  and  representing  those  samples  with  a  number  of  bits.  The  higher  the 
sampling  rate  and  the  higher  the  number  of  representative  bits,  the  higher  the  quality  of  the 
digitized  audio  because  more  information  will  be  available  to  recreate  the  original  analog 
source.  Some  common  sampling  rates  are:  8000  samples  per  second  at  eight  bits  per 
sample,  for  telephone  quality  audio,  and  44000  samples  per  second  at  16  bits  per  sample, 
for  CD  quality. 


2.  Standards 

There  are  several  Codecs  recommended  by  the  ITU  and  other  public  standards 
listed  in  Table  2-2.  Minimum  compliance  is  to  employ  G.71 1 . 


Codec 

Data  Rate 

Comments 

G.711 

48.  56,  64  Kbps 

(Narrowband)  Telephone  quality  audio. 

G.722 

48,  56.  64  Kbps 

(Wideband)  Stereo  quality  audio. 

G,723.1 

5.3  and  6.4  Kbps 

Speech  Coding  at  very  low  rates. 

G.728 

16  Kbps 

Optionally  lower  rate  for  use  in  video  conferences  with 
limited  bandwidth. 

G.729 

8  Kbps 

GSM 

17  Kbps 

(Group  Specials  Mobile)  European  Standard  for 
Cellular  Telephony. 

LPC-10 

2.4  kbps 

U.S.  Federal  Standard 

CELP 

4.8  kbps 

(Code  Excited  Linear  Prediction)  U.  S.  Federal 
Standard 

Table  2-2.  Audio  Codecs  (METRE). 
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3.  Limitations 


Audio  signals  are  sensitive  to  network  delays  as  described  earlier.  Audio 
conferencing  over  a  network  is  typically  not  done  in  stand-alone  mode.  It  is  usuaUy 
bundled  with  whiteboard  or  video  conferencing  tools  to  enable  amplifying  information  to 
be  discussed  along  with  the  presentations  shown  on  the  computer  screen.  If  all  you  are 
going  to  do  is  talk,  you  might  as  well  use  the  phone;  it  is  easy,  cheap,  and  interoperable. 


4.  Bandwidth  Requirements 

Most  commonly  used  measure  for  audio  is  a  minimum  rate  of  64  Kbps,  based  on 
telephone  quality  at  8000  samples  a  second,  8  bits  a  sample.  For  CD  quality  sound,  at 
44000  samples  every  second  and  16  bits  per  sample,  a  “worst  case”  data  rate  of  704  Kbps 
would  be  required. 

Compression  can  be  used  to  lower  these  data  rates  as  well  as  the  mode  of 
operation.  Full  duplex  mode  of  audio  is  being  able  to  hear  and  speak  at  the  same  time. 
This  uses  up  more  bandwidth  since  in  effect  you  will  have  two  streams,  one  in  and  one 
out.  Half-duplex  mode,  in  which  audio  occurs  in  one  direction  at  a  time  triggered  by  the 
person  who  is  speaking,  is  bandwidth  conservative. 

As  an  example,  two  people  conducting  an  audio  conference  with  telephone  quality 
audio,  in  full-duplex  mode,  would  require  a  total  of  128  kbps  to  be  available  at  each 
person’s  workstation  for  64  kbps  audio  going  out  and  64  kbps  audio  coming  in. 
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E.  DESKTOP  VIDEO  CONFERENCING 
1.  Description 

Desktop  video  conferencing  is  the  next  best  thing  to  being  there.  No  longer 
confined  to  the  room-based  equipment  of  the  1980s,  video  is  available  on  your 
workstation  and  is  almost  as  easy  as  using  the  telephone.  Being  able  to  “see”  the  person 
“adds  or  improves  the  ability  to  show  understanding,  forecast  responses,  give  non-verbal 
information,  enhance  verbal  descriptions,  manage  pauses  and  express  attitudes”  (Isaacs). 
Video  conferencing  enables  face-to-face  interactions  with  people  geographically  dispersed, 
without  the  expense,  waste  of  time,  and  inconvenience  of  traveling. 

The  process  of  sending  and  receiving  video  over  the  network  is  the  same  as  for 
audio.  The  analog  video  signal  is  digitized,  compressed  and  transmitted  across  the 
network,  then  decompressed  and  decoded  at  the  receiving  end.  A  workstation  will  require 
a  digital  video  camera,  a  Codec  algorithm,  and  a  video  capture  card,  in  addition  the 
equipment  required  for  audio:  microphone,  speakers,  and  sound  card  (Glover). 

There  are  two  types  of  video:  streaming  and  real  time.  Streaming  video  is  pre¬ 
recorded  video  that  is  stored  on  servers  which  is  played  when  requested  by  a  user,  such  as 
movies  on  demand.  The  other  type  is  real  time  video  where  the  video  source  is  created 
while  watched,  such  as  video  conferencing. 

The  quality  of  the  video  images  is  influenced  by  the  fi-ame  rate  at  which  the  video  is 
transmitted,  the  number  of  bits  used  for  color  depth,  and  the  size  of  the  fi-ame  used. 
Video  is  actually  a  series  of  still  pictures  presented  in  sequence  at  such  a  fast  rate  that  the 
human  eye  perceives  continuous  motion.  Motion  pictures  achieve  this  effect  with  24 
fi-ames  per  second  (fps)  and  television  uses  30  fps.  Typical  desktop  video  ranges  fi-om  4 
Q)Sto  15  ^s. 

Video,  as  displayed  on  your  workstation  monitor,  is  made  up  many  picture 
elements,  “pixels”,  each  of  which  represents  a  small  dot  in  the  overall  image.  Depending 
upon  the  color  distinctions  required,  a  pixel  can  be  represented  by  several  bits  such  as  16 
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bits  for  over  65,000  colors,  or  a  few  bits,  such  as  eight  for  256  colors.  Sbcteen  shades  of 
gray  can  be  represented  in  four  bits  or  in  eight  bits  for  a  finer  resolution. 

There  are  several  frame  sizes  that  can  be  used.  Full  screen  is  640  pbcels  by  480 
pkels,  quarter  screen  is  320  pixels  by  240  pbcels,  and  sbcteenth  screen  is  160  pbcels  by  120 
pbcels.  Standards-based  frame  sizes  are  the  Common  Intermediate  Format  (CIF)  of  352 
pixels  by  288  pixels,  and  the  Quarter  CIF  (QCIF)  which  is  176  pbcels  by  144  pbcels 
(Zeichick). 

2.  Standards 

Video  is  by  far  the  most  bandwidth  demanding  application  of  all  the  collaboration 
tools,  and  compression  technology  is  the  single  biggest  factor  that  has  enabled  video  to 
occur  at  the  desktop.  It  is  also  where  interoperability  between  products  becomes  an  issue. 
Each  participant  in  a  video  session  must  be  using  the  same  compression  algorithms  in 
order  for  the  session  to  even  occur.  A  good  detailed  discussion  of  video  compression  is 
presented  in  Mark  Glover’s  Master’s  Thesis  (Glover). 

Table  2-3  lists  additional  standards  not  mentioned  earlier  in  Section  B. 


Standard 

Description 

H.261 

Compression  for  rates  >  64  Kbps;  defines  CIF,  QCIF 

H.263 

Compression  for  rates  <  64  Kbps 

H.225.0,  H.245 

Communications,  signaling,  and  control  for  conferences  on  packet- 
switched  networks 

MPEG-1 

(Motion  Picture  Expert  Group)  Compression  to  fit  into  1.5  Mbps 
bandwidth 

MPEG-2 

For  rates  between  4  and  9  Mbps 

MPEG-4 

Low  bit-rate  compression  for  rates  <  64  Kbps 

Native  NV 

Xerox  PARC  for  higher  bit  rates 

CellB 

Sun  Microsystems  for  higher  bit  rates 

CUSM 

Cornell  CUSeeMe  Gray  for  lower  bit  rates 

White  Pines  Color 

White  Pines  for  24  bit  color  over  lower  bit  rates 

Table  2-3.  Video  Compression  Standards  (MITRE). 
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3.  Limitations 


The  type  of  information  that  can  be  conveyed  by  video  is  generally  limited  to  what 
can  be  shared  by  seeing  and  hearing  a  person  talking  and  gesturing.  Holding  up  charts  or 
slides  in  front  of  the  camera  for  viewing  by  other  session  participants  is  ineffective  -  the 
resolution  will  not  be  good  enough  for  the  documents  to  be  read.  Other  than  faxing  or 
^mailing  documents  out  prior  to  a  video  session,  other  collaboration  tools  such  as 
whiteboard  or  shared  applications  can  be  used  when  there  are  documents  to  discuss. 
Many  video  products  come  bundled  with  these  capabilities  and  their  use  requires 
additional  bandwidth. 

The  limit  on  the  number  of  video  windows  that  can  be  displayed  on  your  monitor 
simultaneously  can  be  anywhere  from  two  to  twelve  or  more,  with  workstation 
performance  degrading  as  more  video  windows  are  displayed. 

4.  Bandwidth  Requirements 

Acceptable  quality  is  frequently  determined  in  the  eye  of  the  viewer  and  will  be 
constrained  by  the  available  bandwidth.  Most  products  enable  the  user  to  scale  the 
number  of  frames  per  second,  set  a  limit  on  the  amoimt  of  bandwidth  to  be  used,  or  set  the 
amount  of  compression  to  perform.  Video  can  be  compressed  up  to  20:1  and  still  deliver 
a  reasonable  picture  (CISCO). 

Another  technique  to  conserve  bandwidth  is  called  motion  compensation,  in  which 
only  the  bits  in  a  video  frame  which  represent  movement  since  the  last  frame  are 
compressed  and  transmitted.  For  example,  in  a  video  of  a  seated  person  talking,  only  the 
bits  associated  with  the  movement  of  the  person’s  face,  and  the  occasional  head  or  hand 
movement  is  transmitted.  For  the  most  part,  the  rest  of  the  scene  in  the  video  is  static  and 
the  bits  would  not  be  refreshed  as  often. 

Table  2-4  gives  a  feel  for  how  many  bits  are  required  for  one  second  of  video  for 
two  frame  sizes  (CIF,  QCIF),  using  four  bits  per  pixel  (for  16  shades  of  gray),  and  varying 
frames  per  second  from  4  Q)s  to  15  ^s.  The  numbers  derived  in  the  frame  compression 
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column  were  simply  calculated  to  give  an  idea  of  what  a  20:1  compression  ratio  would  be 
and  they  are  not  the  exact  numbers  a  Codec  algorithm  might  derive  for  a  20:1  ratio 
setting. 


Frame  Size 

Total 

pixels/frame 

Number  of 
gray  bits 

Total 

bits/frame 

Frame 

Compression 

(20:1) 

Frame  rate 
(fps) 

Total  Bits  for  one 
second  of  Video 

CIF 

t352X288) 

101,376 

4 

405,504 

20275 

4 

81,100 

CIF 

(352X288) 

101,376 

4 

405,504 

20275 

15 

304,140 

QCIF 

(176  X  144) 

25,344 

4' 

101,376 

5069 

4 

20,276 

QCIF 

(176  X  144) 

25,344 

4 

101,376 

5069 

15 

76,035 

Table  2-4.  Total  Bits  for  One  Second  of  Video  (Author). 


Based  on  Table  2-4,  a  minimum  of  about  20  Kbps  would  be  needed  for  a  video 
conference  transmitting  at  4  frames  per  second.  At  this  frame  rate,  any  movements  at  the 
source  may  appear  jumpy  to  the  receiver,  but  a  meaningful  interaction  is  still  possible. 
Now,  add  64  Kbps  for  audio  and  the  total  bandwidth  required  would  be  about  84  Kbps  for 
each  participant.  In  a  conference  with  two  people,  each  workstation  would  need  at  least 
168  Kbps:  84  Kbps  for  outgoing  video  and  audio  and  84  Kbps  for  the  incoming  video  and 
audio. 


F.  WHITEBOARD 


1.  Description 

Conference  rooms  usually  have  a  whiteboard  or  blackboard  present  for  use  during 
meetings  to  draw  diagrams  or  charts,  list  issues,  or  record  action  items.  Electronic 
whiteboards  cany  this  same  concept  to  your  computer  screen  and  across  the  network.  A 
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picture  is  displayed  as  a  backdrop  and  each  participant  in  the  session  uses  a  uniquely 
colored  marker  to  gesture,  point,  draw,  or  type  text  on  top  of  the  picture  in  a  non¬ 
destructive  mode.  What  you  see  on  your  screen  is  what  everyone  else  sees  and  shrinking 
or  scrolling  the  picture  will  change  everyone’s  view. 

The  displayed  pictures  can  be  maps,  charts,  imagery,  still  video,  or  briefing  slides 
which  are  imported  or  captured  from  other  applications  and  pasted  or  “snapped”  into  the 
whiteboard  area.  Any  participant  can  snap  in  a  new  backdrop  picture  during  the 
whiteboard  session.  Completed  whiteboards  with  annotations  can  be  exported  and  saved 
for  later  reference  by  any  of  the  participants. 

Whiteboard  combined  with  audio  has  been  called  the  “premier  collaboration  tool” 
due  to  the  ease  at  which  a  wide  range  of  information  can  be  shared  among  geographically 
dispersed  people  in  real  time  from  a  network  workstation  (MITRE). 


2.  Standards 

ITU  T.126  defines  a  protocol  for  viewing  and  annotating  still  images  transmitted 
between  two  or  more  applications,  often  referred  to  as  document  conferencing  or  shared 
white  board. 

3.  Limitations 

The  number  of  participants  should  be  kept  low  to  ensure  a  productive  session.  In 
fact,  many  products  have  limitations  on  the  number  of  uniquely  colored  markers  that  are 
available,  ranging  from  eight  to  15.  Whiteboard  is  best  when  used  with  text  chat  or  audio 
to  enable  participants  to  provide  running  commentary  about  the  annotations  they  place  on 
the  displayed  pictures.  This  will  increase  the  bandwidth  required  for  the  collaborative 
session. 

Interoperability  issues  between  products  exist  due  to  the  different  ways  vendors 
implement  the  operations  the  annotation  tools  perform  on  the  picture  backdrops  and  how 
the  whiteboard  session  is  established  and  controlled. 
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Not  all  file  types  can  be  imported  or  exported.  Many  products  can  not  import 
Graphical  Interchange  Format  (GIF)  files  or  export  to  National  Imagery  Transmission 
Format  Standard  (NITFS)  (MITRE). 


4.  Bandwidth  Requirements 

A  whiteboard  session  is  bursty  in  nature,  as  there  is  an  increase  in  the  bandwidth 
required  when  a  backdrop  picture  is  initially  distributed  to  all  participants.  The  size  of  the 
burst  depends  on  the  type  of  picture  transmitted,  whether  it  is  a  chart,  map,  briefing  slide, 
or  still  image.  Table  2-  5  provides  examples  of  relative  sizes  of  document  types  that  may 
be  used  in  whiteboard  sessions.  The  annotations  that  occur  on  the  backdrop  picture  use 
relatively  low  amounts  of  bandwidth,  about  2.4  kbps  per  participant  (MITRE). 

In  general,  a  whiteboard  session  will  tend  to  use  less  bandwidth  than  the 
accompanying  audio  (Floyd). 


1 

Fkture 

Size(pixds 

bypisds) 

Total  Bytes 

ElSSSS* 

1 

\^feate  -  Qniait  Satdlite  Vim  (Korea) 

384  X256 

196824 

1574592 

78730 

2 

Weather  -  Foiecast 

400  X300 

240216 

1921728 

96086 

■ 

Imagsiy  (West  Ba^idad) 

1119X739 

1648856 

13190848 

659542 

4 

E^drogr^c  (]haU  (Mndsenat) 

514X692 

987608 

7900864 

395043 

5 

Topogiai^cal  1:20,000  Scale 

1087  X658 

1432024 

11456192 

572810 

6 

MS  Rnreipoiiit  Slide  (gt^cs) 

118000 

944000 

47200 

7 

MS  Rjvretpamt  Side  (text) 

72000 

576000 

28800 

Table  2-  5.  Picture  Bit  Sizes  (NIMA,  Author). 


G.  METHOD  OF  NETWORK  DELIVERY 


Communication  among  human  beings  can  occur  in  these  formats:  person  to  person, 
from  one  speaker  to  a  large  audience,  and  from  many  people  to  many  people  as  in  a 
meeting  or  via  a  bulletin  board.  Collaboration  tools  have  evolved  and  enable  humans  to 
continue  these  forms  of  communications  over  computer  networks.  Many  computer 
communications  are  point  to  point,  such  as  email  from  sender  to  receiver,  file  downloads, 
web  accesses,  clients  accessing  servers  to  run  applications.  Many  to  many  or 
“multipoint”  communications  can  take  place  with  the  use  any  of  the  collaboration  tools 
described  in  this  chapter,  but  these  applications  are  bandwidth  intensive.  Compression  is 
one  technique  used  to  conserve  bandwidth.  Another  approach  is  to  streamline  delivery 
across  networks.  There  are  three  general  methods  for  multipoint  delivery:  Unicast, 
Broadcast,  and  Multicast.  Figures  2-1,  2-2,  and  2-3  graphically  describe  these  methods. 


1.  Unicast 

In  this  method,  the  sender’s  application  transmits  one  copy  of  each  packet  of 
information  to  each  conference  participant  using  individual  addresses.  This  method  does 
not  scale  well  to  large  groups  and  wastes  bandwidth  since  multiple  copies  may  travel 
shared  paths  through  the  network.  The  burden  in  this  method  is  on  the  sender’s  host 
computer,  which  must  send  out  the  same  number  of  information  packet  copies  as  the 
number  of  intended  receivers.  Delays  in  transmission  will  occur  when  the  sender  is 
bandwidth  limited. 

In  a  collaborative  session,  the  sender  may  be  sending  out  audio  and/or  video 
streams  to  two  other  participants,  as  well  as  receiving  audio  and/or  video  streams  from  the 
two  participants.  Therefore,  in  an  audio  conference  using  64  kbps  audio,  the  sender 
would  be  sending  128  kbps  and  receiving  128  kbps.  A  total  of  256  kbps  must  be  available 
at  the  sender’s  workstation. 
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2.  Broadcast 


A  sender’s  application  transmits  one  copy  of  each  packet  of  information  using  a 
reserved  address  for  broadcast  traffic.  The  information  is  delivered  to  everyone  on  the 
network  regardless  of  the  need  for  the  information.  Those  nodes  that  do  not  need  the 
information  just  discard  it.  This  method  is  extremely  wasteful  of  bandwidth  in  situations 
where  only  a  small  number  of  nodes  want  to  receive  the  information.  In  this  case,  the 
bandwidth  burden  is  placed  on  the  network  itself  and  its  available  capacity. 

For  use  in  a  collaborative  session,  video  could  be  broadcast  from  the  site  where  the 
speaker  is  out  to  the  other  session  participants,  thereby  reducing  the  number  of  outgoing 
streams  from  the  sender  but  the  communication  will  be  one-way  only.  Broadcast 
transmission  is  also  good  for  distributing  static  information  such  as  pictures  for 
whiteboard  sessions. 


3.  Multicast 

This  method  enables  the  sender  to  send  one  copy  of  each  packet  of  information 
using  a  reserved  address  designated  for  nodes  that  want  to  receive  the  information.  As  the 
packets  traverse  the  network,  multicast  routers  are  on  the  lookout  for  this  special  address 
on  behalf  of  interested  nodes  in  their  subnets.  If  a  multicast  router  has  no  nodes  interested 
in  the  packets,  it  forwards  the  packets  on  to  the  next  hop.  If  there  is  interest,  the  multicast 
router  will  replicate  the  number  of  copies  needed  and  deliver  the  packets  to  those  specific 
nodes  within  its  subnet.  For  an  in-depth  technical  discussion  of  IP  Multicast,  refer  to 
(Glover).  In  general,  overall  network  bandwidth  use  is  minimized  since  the  number  of 
duplicate  network  paths  the  packets  take  is  reduced.  However,  store  and  forward  or 
processing  delays  may  be  increased  at  the  multicast  routers. 

This  method  also  significantly  reduces  the  amount  of  bandwidth  required  at  a 
sender’s  workstation.  For  example,  in  the  audio  conference  as  described  above,  with 
multicast  delivery,  the  sender  would  only  send  out  64  kbps  of  audio  for  delivery  to  two 
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other  participants  and  receive  in  128  kbps  (two  audio  streams  from  other  participants)  for 
a  total  of  192  kbps. 


H.  SPECIFIC  APPLICATIONS 

The  Defense  Information  Infrastructure  Common  Operating  Enviroiment 
Multimedia/Collaborative  Services  Technical  Working  Group  (DII  COE  MCSTWG)  has 
been  established  as  part  of  the  DII  COE  and  is  tasked  to  define  a  common  core  of  required 
capabilities  for  collaboration  software  services.  Appendk  A  contains  lists  of  these 
requirements  for  audio,  video,  and  whiteboard  applications. 

This  working  group  also  conducted  an  evaluation  of  audio,  video,  and  whiteboard 
commercial  off  the  shelf  products  in  1997,  the  results  of  which  are  contained  in  Appendk 
B.  In  general,  many  of  the  products  currently  available  provide  point  to  point  sessions  or 
multipoint  sessions  through  the  use  of  Multipoint  Conference  Servers;  multicast  dehvery 
has  not  yet  been  widely  implemented. 


1.  SUMMARY 

Collaboration  tools  offer  many  new  communication  capabilities  via  computer 
networks.  Each  tool  has  varying  uses  and  benefits,  but  no  one  tool  can  do  it  all.  The 
nature  of  the  information  to  be  shared  and  the  available  bandwidth  will  determine  which 
tool  will  be  effective.  Possessing  a  variety  of  these  tools  will  provide  greater  flexibility 
and  adaptability  in  situations  when  collaboration  with  geographically  dispersed  people  is 
required. 


25 


26 


in.  AMPHIBIOUS  PLANNING 


A.  OVERVIEW 

The  planning  process,  the  participants  and  the  types  of  information  discussed  during 
planning,  is  described  in  this  chapter  and  provides  the  basis  for  the  operational  scenario  of 
the  simulation  model  built  to  analyze  bandwidth  requirements  required  for  collaborative 
planning  by  amphibious  ships. 


B.  ORGANIZATION 

Amphibious  ships  regularly  conduct  their  operational  deployments  as  an  Amphibious 
Ready  Group  (ARG)  which  consists  of  three  ships  (EWTG): 

•  Amphibious  Assault  General  Purpose  Ship  (LHA)  or  Multi-Purpose  Ship 
(LHD).  This  ship  is  the  lead  or  “flagship”  of  the  ARG  and  will  have  the 
Amphibious  Squadron  (PHBBRON)  and  Marine  Expeditionary  Unit  (MEU) 
Staffs  embarked.  The  mission  of  the  ship  is  to  embark,  deploy,  and  land 
elements  of  a  landing  force  in  an  assault  by  hehcopters,  landing  craft  and 
amphibian  vehicles. 

•  Amphibious  Transport  Dock  (LPD)  ship  to  transport  and  land  troops  and  their 
equipment  and  supplies  by  means  of  embarked  landing  craft  and  amphibious 
vehicles  augmented  by  helicopter  lift. 

•  Amphibious  Dock  Landing  (LSD)  ship.  This  ship  transports  and  lands  troops, 
equipment  and  supplies  of  the  landing  force  by  means  of  embarked,  pre-loaded 
landing  craft  and  amphibian  vehicles.  Usually  acts  as  the  Landing  Craft,  An- 
Cushioned  (LCAC)  control  ship  in  an  amphibious  operation. 
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At  any  time  during  an  ARG  deployment,  one  or  two  of  the  ships  may  be  temporarily 
detached  to  perform  a  specific  mission,  such  as  advance  force  preparations.  This 
configuration  is  called  a  “Split  ARG”  and  the  operating  distances  are  relative  and  can 
range  anywhere  within  the  ARG’s  assigned  geographical  theater  of  operations.  (Clark) 

When  an  Initiating  Directive  order  is  issued  the  planning  phase  of  an  amphibious 
operation  is  started  and  the  ARG  is  transitioned  into  an  Amphibious  Task  Force  (ATF) 
and  Landing  Force  (LF)  for  the  purpose  of  conducting  an  amphibious  operation.  The 
ARG  forces  are  supplemented  to  form  an  ATF  composed  of  a  primary  control  ship,  a 
secondary  control  ship,  landing  craft,  transport  ships,  a  screen  and  surface  action  group, 
minesweepers,  and  AAW/fire  support/ASW  ships.  The  senior  Navy  officer  is  designated 
the  Commander,  Amphibious  Task  Force  (CATF).  The  Landing  Force  is  commanded  by 
the  senior  landing  force  officer,  usually  a  Marine  Corps  officer  but  could  be  an  Army 
Officer,  and  is  composed  of  a  Battalion  Landing  Team  and  Regimental  Landing  Team. 
Other  forces  may  include  the  U.  S.  Air  Force,  garrison  forces,  and  base  construction 
forces.  The  CATF  and  CLF  are  positioned  onboard  the  ATF  flagship,  an  LHA  or  LHD, 
and  it  is  onboard  this  ship  where  the  primary  planning  for  the  operation  occurs.  (Kim, 
EWTG) 

C.  OPERATIONS 

In  general,  there  are  four  types  of  amphibious  operations  and  the  conduct  of  each 
operation  is  executed  following  a  five-phase  sequence  of  events. 

1.  Types 

Amphibious  operations  can  be  categorized  as  follows  (Joint  Pub  3-02): 

•  Amphibious  Assault,  which  involves  establishing  a  force  on  a  hostile  or 
potentially  hostile  shore. 
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•  Amphibious  Demonstration.  An  operation  using  a  show  of  force  meant  to 
deceive  the  enemy  into  executing  an  unfavorable  course  of  action  to  its  own 
forces. 

•  Amphibious  Raid.  An  operation  which  involves  a  swift  incursion  into  or  a 
temporary  occupation  of  an  objective  prior  to  a  planned  withdrawal.  Raids  are 
conducted  to  inflict  loss  or  damage,  secure  information,  create  a  diversion, 
capture  or  evacuate  individuals  and/or  material,  and  execute  deliberate 
deception  operations.  Non-combatant  Evacuation  Operations  (NEO)  is  a  type 
of  Amphibious  Raid. 

•  Amphibious  Withdrawal  to  remove  forces  from  hostile  or  potentially  hostile 
shore  to  sea  in  naval  ships  or  craft. 

2.  Phases 

Amphibious  operations  follow  a  well-defined  sequence  of  events  organized  into 
five  phases; 

•  Planning.  Starts  when  an  Initiating  Directive  order  is  issued  to  the 
Commander,  Amphibious  Task  Force  (CATF)  and  is  done  continously 
throughout  the  operation.  Planning  is  done  in  parallel  and  concurrently  among 
the  staffs  of  the  CATF,  CLF,  and  other  participating  forces.  So  much  planning 
must  occur  that  Joint  Pub  3-02  states  that  the  nature  of  the  planning: 

favors  the  assembly  of  commanders  and  staffs  of 
corresponding  echelons  in  the  same  locality.  If  such  arrangement  is  not 
practicable,  the  exchange  of  liaison  officers  qualified  to  perform  essential 
planning  is  necessary. 
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•  Embarkation.  Period  of  time  in  which  the  forces,  with  their  equipment  and 
supplies,  embark  onto  their  assigned  shipping. 

•  Rehearsal.  The  perspective  operation  is  rehearsed  for  the  purposes  of  testing 
plans,  timing,  combat  readiness,  testing  communications,  and  ensuring  all 
participants  are  familiar  with  the  plan. 

•  Movement.  During  this  period,  the  various  elements  of  the  ATF  move  to  the 
points  of  embarkation  to  the  Amphibious  Objective  Area,  and  this  phase  is 
completed  when  all  ATF  forces  arrive  at  their  assigned  positions. 

•  Assault.  The  timeframe  between  the  arrival  of  the  major  assault  forces  of  the 
ATF  in  the  landing  area  to  the  accomplishment  of  the  ATF  mission. 


D.  PLANNING  PROCESS 

There  are  two  types  of  processes  employed  -  deliberate  and  rapid  response;  the 
primary  difference  between  the  two  is  the  time  allocated  to  perform  the  planning. 
Deliberate  planning  occurs  continuously  within  an  ARG  to  maintain  a  state  of  readiness 
and  ability  to  quickly  respond  to  any  contingencies  that  may  flair  up  during  their 
deployments.  Rapid  Response  planning  is  the  deliberate  planning  process  compressed  into 
a  six  hour  evolution. 


1.  Deliberate  Planning 

There  are  15  deliberate  planning  steps  (EWTG): 

1 .  Receipt  of  the  mission  via  Initiating  Directive  by  the  CATF  and  CLF. 
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2.  Mission  Analysis.  Determine  the  Higher  Commander’s  intent,  the 
purpose,  the  tasks  required  to  achieve  the  purpose,  and  any  tactical, 
political,  time  and  space,  weather,  or  rules  of  engagement  limitations. 
Develop  assumptions  about  friendly  and  enemy  force  capabilities  and 
identify  critical  vulnerabilities,  capabilities,  and  requirements. 

3.  Determine  information  requirements  with  regards  to  intelligence  and 
friendly  forces  required  by  the  Commander  for  the  successful  execution 
of  the  operation.  The  information  may  be  obtained  from  sources  such 
as  maps,  charts,  imagery,  groimd  sensors,  enemy  signal 
communications,  enemy  documents,  intelligence  documents,  and 
weather  forecasts. 

4.  Initial  Staff  Orientation.  The  CATF  and  CLF  will  each  conduct 
separate  meetings  with  their  staffs  who  are  called  upon  to  speak  in  then- 
area  of  expertise  with  respect  to  the  operation  and  contribute 
knowledge  in  such  as  areas  as  terrain,  hydrography,  the  area  of 
operations,  enemy  capabilities,  available  forces,  and  logistics  support. 

5.  Commander’s  Plamiing  Guidance.  The  CATF  and  CLF  staffs  get 
together  to  discuss  the  operation  and  the  initial  basic  decisions  that 
must  be  made  before  detailed  planning  can  proceed.  The  decisions  are: 
ATF  general  course  of  action,  objectives,  the  Landing  Force  mission, 
objectives  and  concept  of  operations,  the  landing  site,  beachheads  and 
landing  areas,  helicopter  landing  zones,  and  the  D-Day  and  H-Hour. 

6.  CATF  and  CLF  Commanders  issue  planning  directives  that  provide  the 
schedule  and  the  instructions  covering  the  planning  process  execution. 
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7.  CATF  and  CLF  Commanders  provide  initial  planning  guidance,  their 
philosophies  and  issues  regarding  the  operation  and  the  overall  plan  to 
their  staffs  to  assist  in  focusing  course  of  action  development. 

8.  Develop  courses  of  action  for  accomplishing  the  mission  via 
collaboration  between  the  CATF  and  CLF  staffs. 

9.  CATF  and  CLF  commanders  are  briefed  on  a  range  of  proposed 
courses  of  action  and  approve  a  general  set  of  potential  actions. 

10.  The  staffs  conduct  estimates  of  supportability  of  the  general  set  of 
selected  courses  of  action  using  the  criteria  of  suitability,  feasibihty, 
acceptability,  and  completeness. 

11.  Commander’s  Estimate  document  is  prepared. 

12.  Development  of  the  Concept  of  Operations  which  describes  how  the 
commander  intends  to  use  the  forces  at  hand  to  accomplish  the  mission. 

13.  Preparation  of  detailed  plans  on  selected  course  of  action. 

14.  Approval  of  the  plan  by  the  Commander. 

15.  Continued  supervision  by  the  Commander  and  Staff  to  ensure  the  plan 
is  updated  until  required  or  executed  as  intended. 
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2.  Rapid  Response  Planning 

When  amphibious  units  are  required  to  conduct  a  rapid  execution  of  certain 
missions,  the  planning  process  is  compressed  into  six  hours,  and  emphasis  is  placed  on 
using  verbal  briefs  with  standardized  slide  formats  vice  generating  written  documents. 
The  six  hours  are  allocated  as  follows; 

•  First  hour  and  30  minutes  is  spent  on  the  first  12  steps  of  the  deliberate 
planning  process  listed  previously.  Primary  plaiming  location  is  onboard  the 
ATF  Flagship  and  conducted  by  a  Crisis  Action  Team  (CAT).  The  CAT 
consists  of  the  PHIBRON  Commanding  Officer,  N2,  N3,  N4,  N5,  and  N6;  the 
MEU  Commanding  Officer,  Executive  Officer,  S2,  S3,  S4,  S6,  and  Staff  Judge 
Advocate;  a  meteorologist,  major  subordinate  elements  of  the  Landing  Force, 
and  any  other  individuals  the  CATF  or  CLF  designate.  During  this  timefi’ame, 
various  information  is  shared:  the  meteorologist  provides  a  weather  brief;  N2 
/S2  provides  intelligence,  enemy  order  of  battle,  threat  and  country  briefs; 
N3/S3  discuss  landing  areas  with  maps  and  charts;  the  Staff  Judge  Advocate 
covers  the  Rules  of  Engagement;  N3/S3  briefs  the  status  of  fiiendly  forces;  and 
the  PHIBRON  and  MEU  commanders  deliver  their  initial  planning  guidance. 

•  One  hour  and  30  minutes  is  spent  developing  detailed  plans. 

•  One  hour  is  spent  conducting  a  confirmation  brie^  which  covers  the 
commander’s  approval  of  the  plan  the  concept  of  operations.  The  execution 
order  is  issued  verbally. 

•  Last  two  hours  are  used  to  brief  the  troops,  complete  readiness  checklists,  and 
to  conduct  drills  and  rehearsals. 


33 


E.  PARTICIPANTS 


Currently,  many  of  the  primary  planning  participants  are  organic  to  the  ATF  and 
located  onboard  the  flagship.  If  not  already  onboard,  the  appropriate  personnel  are 
delivered  via  helicopter  to  the  flagship  in  order  to  conduct  face-to-face  meetings.  If 
representation  is  needed  at  the  Joint  Task  Force  level,  ATF  liaison  ofiBcers  are  placed 
onboard  the  JTF  Command  ship. 

Emphasis  on  "joint"  (more  the  one  Service  is  involved)  or  "combined"  (forces  other 
than  U.S.  only  are  also  participating)  operations  in  response  to  global  contingencies  only 
serves  to  increase  the  necessity  of  collaboration  and  coordination  by  the  ATF  or  ARG 
vwth  outside  organizations.  Planning  must  be  conducted  across  Services  or  Combatant 
command  staffs  and  with  other  countries'  staffs  to  compose  situation  assessments,  develop 
courses  of  action,  and  to  coordinate  resources.  Additional  expertise  may  be  required 
from  outside  organizations,  such  as  a  Joint  Intelligence  Center,  National  Imagery  and 
Mapping  Agency  (NIMA),  a  weather  center.  Modeling  and  Simulation  centers  for  course 
of  action  analysis,  and  from  other  federal  agencies  such  as  the  State  or  Commerce 
Departments,  in  order  to  plan  an  amphibious  operation. 
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IV.  MODEL  SETUP 


A.  OVERVIEW 

As  a  general  representation  of  collaborative  planning  conducted  by  an  Amphibious 
Ready  Group  (ARG),  a  nine  node,  three  router  network  was  built  and  the  flow  of  audio, 
video,  and  whiteboard  information  among  the  nodes  was  simulated.  This  chapter  will 
provide  details  on  the  simulation  modeling  tool  used,  the  operational  scenario  considered, 
how  the  collaborative  sessions  were  derived  as  well  as  other  model  parameters,  and  the 
type  and  number  of  model  runs  conducted. 


B.  SIMULATION  MODELING  TOOL 

An  object-oriented  modeling  program  developed  by  Imagine  That,  Inc.,  called  Extend, 
was  used  to  build  a  nine  node,  three  router  network.  Extend  can  be  purchased  for  under 
$1000.00.  Minimum  system  requirements  include; 

•  Windows  3. 1+,  95,  or  NT  4.0+ 

•  486  or  Pentium-type  processor  with  at  least  16  MB  RAM  and  24  MB  hard 
disk  space 

The  specific  machine  used  was  a  Gateway  2000,  Pentium  H  300  MHz  processor,  with 
32  Megabytes  RAM,  two-gigabyte  hard  drive  and  Windows  95  operating  system.  Minor 
problems  were  experienced  with  an  Extend  “out  of  memory”  error  that  prevented  some 
model  runs  from  being  simulated  for  the  desired  amount  of  time.  The  affected  model  runs 
are  pointed  out  in  Section  E  of  this  chapter. 
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C.  OPERATIONAL  SCENARIO 

The  operational  backdrop  for  the  network  modeled  was  loosely  based  upon  the 
amphibious  planning  process  used  by  an  ARG  for  planning  a  landing.  The  types  of 
information  most  likely  to  be  shared  and  the  number  of  participants  involved  during 
planning  were  derived  from  the  material  presented  in  Chapter  m.  Current  planning 
practices  involve  interactions  among  personnel  primarily  located  on  the  ARG  Flagship, 
which  can  be  considered  as  one  node  in  a  network.  In  the  simulation  model,  a  range  of 
locations  is  used,  from  two  to  nine  nodes,  to  portray  planning  in  a  more  distributed 
environment. 


D.  MODEL  PARAMETERS 

The  objective  of  the  simulation  model  was  to  analyze  various  combinations  of 
bandwidth,  type  of  collaboration  session,  network  delivery  method,  and  number  of  session 
participants,  in  an  effort  to  derive  a  desirable  bandwidth  for  collaborative  planning.  There 
were  four  significant  parameters  used  in  the  model  and  their  descriptions  follow. 


1.  Bandwidth 

Three  bandwidth  settings  were  used:  128  kbps,  256  kbps,  and  384  kbps,  which 
were  derived  from  the  matrix  listed  in  Appendix  C.  All  collaboration  participants  were 
assumed  to  have  the  same  amount  available.  Varying  the  bandwidth  amounts  among  the 
network  nodes  was  not  simulated.  Collaboration  tools  are  used  to  perform 
communications  in  real-time.  Possessing  a  higher  bandwidth  provides  no  speed  advantage 
over  a  lesser-equipped  site  since  both  sites  are  communicating  together,  at  the  same  time. 
The  site  with  higher  bandwidth  will  actually  be  constrained  to  operate  at  the  lower 
bandwidth  level  of  the  least  capable  participant,  so  all  nodes  in  the  model  were  modeled 
with  the  same  amount. 


36 


2.  Number  of  Collaboration  Participants 

Two,  three,  six,  and  nine  nodes  were  used  to  simulate  conununications  among  two 
or  three  ships  in  an  ARG  and  the  ARG  with  three  or  six  other  sites.  These  other  sites 
represented  a  Carrier  Battle  Group  or  shored-based  sites  such  as  support  elements  for 
landing  team,  weather  centers  or  intelligence  centers.  Fleet  Staffs,  and  other  Services  or 
government  agencies,  any  one  of  which  may  play  a  part  during  the  collaborative  planning 
process  being  conducted  by  the  ARG. 


3.  Network  Delivery  Method 

Two  delivery  methods  were  simulated:  Unicast  and  Multicast,  which  were 
described  in  Chapter  II.  Maximum  node  participation  was  assumed  in  both  methods.  In  a 
nine  node  Unicast  scenario,  a  node  would  send  out  eight  individual  text  chat,  audio,  video 
or  whiteboard  bit  streams  destined  for  the  eight  other  nodes.  In  a  nine  node  Multicast 
scenario,  a  node  would  send  out  one  text  chat,  audio,  video,  or  whiteboard  bit  stream  and 
the  routers  would  replicate  and  route  the  bit  streams  to  reach  the  eight  other  nodes. 

The  specific  details  of  packet  delivery,  losses  and  retransmissions  and  various  types 
of  routing  protocols  were  not  modeled.  The  high  level  effect  of  modeling  these  two 
delivery  methods  was  to  stress  the  bandwidth  available  at  a  node  as  the  node  attempted  to 
send  out  the  required  number  of  audio  and  video  streams  to  other  nodes  participating  in  a 
collaborative  session. 


4.  Collaboration  Sessions 

The  exact  nature  of  the  information  to  be  discussed  at  any  particular  time  during  a 
planning  session  will  not  always  be  known  or  the  same  each  time  planning  is  conducted. 
Fortunately,  the  information  to  be  shared  during  a  collaboration  session  does  not  have  to 
be  modeled  explicitly.  Each  collaboration  tool  and  its  use  in  combination  with  others 
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provides  the  means  to  transport  the  planning  information  across  the  netvyork,  and  it  is  the 
capacities  of  these  tools  that  can  be  modeled.  The  following  paragraphs  describe  the  13 
different  collaboration  sessions  used  in  the  model  and  how  they  were  derived. 

a.  Text  Chat 

A  generic  message  size  was  set  at  100  words.  Assuming  an  average  of  five 
characters  per  word  and  using  eight  bits  per  character,  the  text  chat  message  size  was  set 
at  4000  bits.  For  a  text  chat  collaborative  session  it  was  assumed  that  each  node  would 
send  out  a  message  every  Vi  minute  and  more  than  one  node  could  put  out  a  message  at  a 
time.  The  nodes  did  not  have  to  take  turns  or  wait  for  messages  for  other  nodes  to  arrive 
prior  to  sending  out  any  messages. 

b.  Audio  Conferencing 

Full  duplex  mode  was  used  so  each  node  could  hear  and  speak  simultaneously. 
Nodes  did  not  have  to  take  turns  to  speak.  Using  rates  derived  fi'om  the  matrix  in 
Appendix  C,  two  sessions  were  built: 

•  Low  rate  audio  of  14.4  kbps. 

•  Ifigh  rate  audio  of  64  kbps. 


c.  Video  Conferencing 

Video  Conferencing  was  not  done  in  stand-alone  mode,  all  sessions  included 
audio.  As  in  the  audio  conference  sessions,  audio  was  in  full-duplex  mode  and  nodes  did 
not  have  to  take  turns  to  speak.  All  nodes  could  see  video  and  hear  audio  fi’om  each  of 
the  other  participant  nodes  simultaneously.  Video  was  based  on  the  QCIF  jframe  size  of 
176  pixels  by  144  pixels,  grayscale  with  four  bits  per  pixel,  fi’ame  compression  rate  of 
20:1,  and  a  low  rate  of  4  frames  per  second  (Q)s)  and  a  high  rate  of  15  ^s.  Table  2-4 
shows  the  bit  sizes  derived  for  one  second  of  video  with  these  characteristics.  The 
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resulting  coinbinations  of  low  audio  and  video  with  high  audio  and  video  generated  four 
video  conference  collaborative  sessions: 


•  Video  at  4  Qis  and  Audio  at  14.4  kbps,  for  a  total  of 34,676  bits  per  second. 

•  Video  at  4  Qis  and  Audio  at  64  kbps,  for  a  total  of  84,276  bits  per  second. 

•  Video  at  15  fps  and  Audio  at  14.4  kbps,  for  a  total  of  90,435  bits  per  second. 

•  Video  at  1 5  fys  and  Audio  at  64  kbps,  for  a  total  of  140,035  bits  per  second. 

d  Whiteboard 

Whiteboard  sessions  tend  to  be  bursty  in  nature  as  the  pictures  for  backdrops 
are  initially  sent  to  all  participants  then  displayed  for  a  period  of  time  to  enable  annotations 
and  discussion.  During  a  session,  it  was  assumed  that  a  single  node  would  transmit  all 
whiteboard  pictures  to  each  of  the  other  nodes.  All  nodes  were  sending  audio  and  video 
to  the  other  nodes  while  waiting  for  the  whiteboard  pictures  to  arrive.  In  a  collaborative 
session,  productive  discussions  could  continue  during  this  waiting  period  while  the 
whiteboard  backdrop  pictures  are  updated.  The  receiving  nodes  could  not  begin 
annotations  until  the  picture  had  been  received  and  then  the  nodes  took  turns  to  annotate. 
For  example,  in  a  three  node  scenario,  each  node  would  have  to  wait  two  time  steps 
before  sending  its  annotation  bit  stream  of  2.4  kbps.  Picture  5,  the  topographical  map 
consisting  of  572,810  bits  was  selected  from  Table  2-5  and  used  as  the  picture  transmitted 
in  the  whiteboard  session.  This  map  is  a  good  example  of  what  might  be  displayed  during 
an  Amphibious  Landing  collaborative  planning  session.  Like  video  conferencing, 
whiteboard  is  typically  not  done  alone  -  it  is  usually  accompanied  by  audio  or  video  and 

audio  together.  Whiteboard  combined  with  the  various  audio  and  video  rates  resulted  in 
six  sessions: 
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•  Whiteboard  (Wb)  and  Audio  at  14.4  kbps. 

•  Wb  and  Audio  at  64  kbps. 

•  Wb  and  Video  at  4  Q)s  and  Audio  at  14.4  kbps. 

•  Wb  and  Video  at  4  fps  and  Audio  at  64  kbps. 

•  Wb  and  Video  at  1 5  fps  and  Audio  at  14.4  kbps. 

•  Wb  and  Video  at  1 5  fps  and  Audio  at  64  kbps. 


E.  MODEL  RUNS 

Over  170  different  variations  of  the  basic  model  were  executed.  A  discussion  of  the 
Extend  model  structures  that  were  buUt,  the  measure  of  effectiveness  used  and  the  various 
run  combinations  are  provided  in  the  following  paragraphs. 

1.  Basic  Model  Structures 

The  node  and  router  structures  used  in  the  model  will  be  described  and  are  shown 
in  Appendbt  D.  These  basic  structures  were  then  used  as  building  blocks  and  replicated  as 
needed  for  a  six  node  or  nine  node  network  model.  Storage  requirements  varied  from 
1,176  Kbytes  to  store  a  two  node  model  file  to  4,200  Kbytes  for  a  nine  node  model  file. 

a.  Node  Structure 

Each  node  sends  out  text  chat,  audio,  or  video  messages  containing  the 
number  of  bits  representing  the  specific  collaborative  session  being  simulated.  Only  one 
node  sends  out  whiteboard  message  bits.  Each  node  also  receives  text  chat,  audio,  video 
messages  from  other  nodes  and  receives  whiteboard  messages  from  one  designated  node. 
Time  Division  Multiple  Access  (TDMA)  mode,  using  a  clock  step  of  2  milliseconds,  was 
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used  to  alternately  allow  designated  outgoing  messages  out  from  the  node  to  the  router 
and  allow  incoming  messages  in  from  the  router  to  the  node.  After  passing  the  TDMA 
gate,  all  messages  are  placed  into  a  common  first-in,  first-out  queue.  No  priorities  were 
assigned  based  on  the  type  of  message  -  each  is  handled  on  a  first-come,  first-served  basis. 
A  transmission  delay  is  then  calculated  using  the  bit  size  of  the  message  divided  by  the 
amount  of  bandwidth  available  at  the  node  to  determine  the  amount  of  time  required  to 
send  or  receive  a  message.  After  the  delay,  outgoing  messages  are  sent  to  the  router  and 
incoming  messages  are  sorted  and  stored  by  source  node. 

b.  Router  Structure 

A  router  has  three  nodes  in  its  subnet.  A  message  destined  for  a  node  within  a 
router’s  subnet  is  sent  directly  to  that  node  by  the  router.  A  messagedestined  for  a  node 
in  another  subnet  is  sent  to  the  router  serving  that  subnet.  In  Unicast  delivery  mode,  the 
router  simply  executes  a  decision  tree  to  decide  which  subnet  nodes  or  routers  are  to 
receive  the  message  and  forwards  the  message  to  those  destinations.  In  Multicast  delivery 
mode,  a  router  replicates  the  message  for  delivery  to  its  subnet  nodes  and  forwards  copies 
of  the  message  to  the  other  routers.  No  delays  were  simulated  for  any  processing  which 
occurs  at  the  routers  or  for  the  transmission  time  required  for  messages  to  reach  the  other 
routers.  In  general,  the  differences  between  the  processing  delays  induced  by  a  regular 
router  and  by  a  multicast  router  are  negligible  (Brutzman,  Macker,  Novotny).  The 
simulation  model  was  built  to  see  how  limiting  the  bandwidth  is  at  the  node  and  not 
throughout  the  network. 


2.  Measure  of  Effectiveness 

For  collaborative  sessions  to  be  viable,  the  amount  of  delay  in  receiving  audio  bit 
streams  must  be  at  least  under  500  milliseconds  and  video  must  be  at  least  under  95 
milliseconds  for  reasons  described  in  Chapter  n.  The  quality  of  service  for  video  is  more 
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subjective  than  audio  and  video  frame  rates  that  simply  provide  an  indication  of  presence, 
not  movement,  at  other  sites  may  be  acceptable  and  not  necessarily  take  away  from  the 
success  of  a  collaborative  session.  Therefore,  more  emphasis  was  placed  on  using  500 
milliseconds  or  less  as  an  acceptable  level  of  delay  for  the  amount  of  time  for  a  text  chat, 
audio,  video  message  to  leave  one  node  and  arrive  at  another  node.  Whiteboard  messages 
tended  to  take  longer  than  500  milliseconds  and  delays  are  a  direct  factor  of  the  size  of  the 
picture  and  the  amount  of  bandwidth  available  to  transmit  and  receive  the  picture. 
Measurements  were  taken  separately  for  whiteboard  simply  to  record  the  amount  of  delay 
that  occurred  in  the  different  parameter  combinations.  Within  the  Extend  models, 
outgoing  messages  were  tagged  as  soon  as  they  were  generated  at  a  node  and  their  arrival 
times  at  the  destination  nodes  were  measured.  Measurements  were  taken  within  a  subnet 
and  across  to  other  subnets  as  follows: 

•  Two  node  scenario.  Node  1  to  node  2  and  node  2  to  node  1  for  text  chat, 
audio,  and  video.  Whiteboard  from  node  1  to  node  2  only. 

•  Three  node  scenario.  Node  1  to  node  2,  node  2  to  node  3,  and  node  3  to  node 
1  for  text  chat,  audio,  and  video.  Whiteboard  from  node  1  to  node  2  and  node 

3. 

•  Six  node  scenario.  Node  1  to  node  6,  node  2  to  node  3,  and  node  6  to  node  1 
for  text  chat,  audio,  and  video.  Whiteboard  from  node  1  to  node  3  and  node  6. 

•  Nine  node  scenario.  Node  1  to  node  9,  node  2  to  node  3,  node  6  to  node  1  for 
text  chat,  audio,  and  video.  Whiteboard  from  node  1  to  node  3,  node  6,  and 
node  9. 
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3.  Simulation  Run  Time 


A  simulation  run  time  of  100  seconds  was  selected.  Extend  required 
approximately  three  minutes  to  execute  a  two  node  model,  four  minutes  for  a  three  node 
model,  1 1  minutes  for  a  six  node  model  and  23  minutes  to  execute  a  nine  node  model. 

Other  simulation  run  times  were  tried:  180  seconds,  which  took  approximately  26 
minutes  for  a  six  node  scenario  to  execute,  240  seconds  which  took  33  minutes,  and.  300 
seconds  which  took  40  minutes  to  execute.  The  measured  delays  from  models  executed 
with  the  longer  simulated  run  times  were  compared  to  those  captured  in  model  runs  for 
100  seconds  and  no  significant  differences  were  noted.  The  delays  appeared  to 
consistently  occur  among  the  nodes  in  similar  patterns  and  at  a  similar  ratios,  so  100 
seconds  was  selected  as  the  simulation  run  time  for  all  models. 

For  the  majority  of  the  runs  executed,  100  seconds  was  more  than  ample  time  to 
get  text  chat,  audio,  video  and  whiteboard  messages  delivered  among  the  nodes. 
Messages  that  took  longer  than  100  seconds  were  well  beyond  the  acceptable  range  as 
described  previously. 


F.  RUN  COMBINATIONS 

With  the  number  of  parameters  described  in  Section  D  above,  many  nm  combinations 
were  possible.  The  strategy  to  reduce  the  number  of  runs  yet  execute  some  meaningful 
combinations  was  to  first  run  combinations  at  each  end  of  the  node  spectrum,  three  and 
nine  nodes,  and  establish  some  “baseline”  runs.  The  next  step  was  to  examine  the  run 
results  against  the  selected  measure  of  effectiveness  and  identify  those  combinations  that 
were  successful.  These  runs  became  the  “focused”  runs  and  the  parameters  were  further 
modified.  “Special”  runs  were  executed  for  a  high-level  look  at  a  point-to-point 
collaboration  scenario  and  two  different  locations  for  a  multicast  router  -  on  a  satellite  or 
at  a  shore  location.  Appendix  E  contains  a  matrix  of  the  various  model  parameter 
combinations  that  were  executed. 
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1.  Baseline  Runs 


The  parameters  used  were  three  and  nine  nodes,  128  and  384  kbps.  Unicast  and 
Multicast  delivery,  and  all  13  different  collaborative  sessions.  The  various  combinations 
resulted  in  a  total  of  104  runs  executed. 

Difficulties  were  encountered  with  runs  that  tended  to  be  at  the  high  end  for 
stressing  the  model:  9  nodes,  128  kbps.  Unicast  delivery,  and  collaborative  sessions  with 
whiteboard,  video  and  audio  combinations.  At  this  bandwidth,  many  nodes  did  not 
receive  any  whiteboard,  video  or  audio  messages  from  some  of  the  other  nodes  during  the 
specified  simulation  run  time  of  100  seconds.  A  larger  simulation  run  time  of  180  was 
selected  and  some  nodes  still  did  not  receive  messages.  A  run  time  of  240  seconds  was 
then  used  and  Extend  ran  out  of  memory  for  building  arrays  used  to  maintain  state 
information  about  the  model.  As  a  result,  several  of  the  nine  node  runs  did  not  generate 
any  data  for  the  measure  of  effectiveness  -  the  amount  of  time  for  a  message  from  one 
node  to  arrive  at  another  node.  Examination  of  the  data  that  was  collected  for  dehvery 
times  to  other  nodes  revealed  that  the  messages  in  those  affected  nine  node  runs  would 
have  been  far  beyond  the  acceptable  range  for  audio  or  video.  The  measured  delays 
recorded  for  the  affected  nine  node  runs  were  set  to  100  seconds  to  reflect  a  “maxed  out” 
state  for  those  runs.  This  clearly  sets  the  affected  runs  apart  from  the  other  successful 
mns  and  is  reflected  in  the  graphs  presented  in  Chapter  V. 


2.  Focused  Runs 

Three  collaborative  session  types  were  selected  from  the  baseline  runs;  video  at  4 
^s  and  audio  at  14.4  kbps,  whiteboard  with  audio  at  14.4  kbps,  and  whiteboard  with 
video  at  4  Q)s  and  audio  at  14.4  kbps.  These  session  types  represent  the  spectrum  of 
capabilities  that  are  offered  by  collaboration  tools,  and  the  rates  selected  show  the  most 
promise  for  message  deliveries  with  the  acceptable  delay  of  500  milliseconds. 


New  runs  were  generated  using  the  parameters:  two,  three,  six,  and  nine  nodes, 
bandwidths  of  128,  256,  and  384  kbps.  Unicast  and  Multicast  delivery  methods,  and  the 
three  collaborative  session  types  mentioned  above.  The  various  combinations  resulted  in  a 
total  of  72  runs  executed. 


3.  Special  Runs 

These  additional  18  runs  were  constructed  to  examine  specific  aspects  in  an 
amphibious  planning  scenario,  such  as  point-to-point  collaboration  between  two  ships  in 
Line  of  Sight  (LOS)  mode  and  the  effect  of  location  of  the  multicast  router  on  message 
delays  for  a  three  ship  ARG.  Two  locations  of  a  multicast  router  were  simulated  -  one 
onboard  a  geostationary  satellite  using  a  240  millisecond  round-trip  propagation  delay  and 
the  other  via  a  geostationary  satellite  link  to  a  shored-based  router  located  at  a  facility 
such  as  a  Naval  Computer  and  Telecommunications  Area  Master  Station  (NCTAMS).  In 
both  multicast  router  scenarios  a  1200  millisecond  generic  router  processing  delay  was 
implemented  (O’Reilly). 

G.  SUMMARY 

An  overall  representation  of  collaboration  planning  conducted  by  an  Amphibious 
Ready  Group  (ARG)  was  built  fi’om  the  aspect  of  the  collaboration  tools  available  and  the 
data  rates  required  for  their  viable  use.  Several  combinations  of  collaboration  tools, 
bandwidths,  participants,  and  network  delivery  methods  were  executed  via  a  simulation 
tool  in  an  effort  to  assess  which  combinations  showed  more  potential  for  success.  No 
delays  associated  with  protocols,  routers  or  network  congestion  were  simulated.  In  effect, 
the  “best  case”  for  text  chat,  audio,  video,  and  whiteboard  message  delivery  was  simulated 
which  only  served  to  highlight  the  impact  that  a  planning  participant’s  available  bandwidth 
has  on  the  conduct  of  a  collaborative  session. 
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V.  MODEL  RESULTS 


A.  OVERVIEW 

Over  170  model  runs  were  executed  in  an  effort  to  provide  some  insight  into  the 
question,  “How  much  bandwidth  is  required  for  collaborative  planning?”  The  amount  of 
bandwidth  available  to  a  ship  will  limit  the  collaboration  tool  that  can  be  used  and  the 
number  of  dispersed  planners  that  can  be  involved  in  a  session  -  the  usual  trade  off 
between  resources  and  capabilities. 

An  examination  of  the  average  message  delays  measured  for  the  various  parameter 
combinations  indicate  that  two  or  three  nodes  can  successfully  conduct  a  wider  range  of 
collaboration  session  types  at  128  kbps  when  Multicast  delivery  is  implemented-  A 
whiteboard  session  with  accompanying  audio  and  video  among  two  or  three  nodes  is 
untenable  at  128  kbps  with  Unicast  implemented.  A  bandwidth  of  256  kbps  enables  up  to 
six  nodes  to  conduct  a  whiteboard  with  audio  session.  An  even  higher  bandwidth  of  384 
kbps  provides  the  ability  of  sbc  nodes  to  collaborate  via  whiteboard  with  video  and  audio 
and  for  nine  nodes  to  get  together  in  a  whiteboard  and  audio  session. 

This  chapter  will  present  the  results  and  interpretations  of  the  Baseline,  Focused  and 
Special  Runs.  Appendix  F  contains  the  Extend  model  results. 


B.  GRAPH  FORMATS 

Two  basic  graph  formats  are  used  to  present  the  results  of  the  model  runs  -  a 
Baseline  graph  and  a  Parameter  graph.  All  the  graphs  are  presented  at  the  end  of  this 
Chapter. 
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1.  Baseline  Graph 

This  graph  compares  the  average  message  delays  of  text  chat,  audio,  video,  and 
whiteboard  messages  among  the  nodes  in  a  three  node  and  nine  node  scenario,  across 
collaboration  session  type.  An  example  is  shown  in  Figure  5-1.  The  title  of  the  graph 
indicates  the  network  delivery  method  and  the  bandwidth  used,  such  as  Unicast  and  128 
kbps.  The  X-axis  lists  the  collaboration  session  types.  The  Y-axis  lists  the  average  delay 
in  seconds  for  a  message  to  travel  between  two  nodes.  The  plot  lines  with  solid  marks 
represent  text  chat  delays  or  audio  and  video  delays  combined.  The  plot  lines  with  open 
marks  represent  whiteboard  delays.  An  example  of  an  observation  from  Figure  5-1  is  that 
the  three  node  scenario  is  the  only  node  scenario  with  an  average  delay  less  than  V^  second 
for  the  whiteboard  and  audio  (14.4  kbps)  session.  Refer  to  Appendix  F  for  actual  delay 
measures. 


Figure  5-1.  Baseline  Graph 
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2.  Parameter  Graph 


The  purpose  of  this  graph  is  to  examine  the  average  delays  for  message 
deliveries  for  a  specific  model  parameter  across  the  remaining  three  model  parameters  and 
identify  trends  or  rates  of  change  in  performance.  Figure  5-2  is  an  example  of  this  graph. 
The  title  indicates  the  parameter  being  examined,  such  as  the  number  of  nodes.  The  X- 
axis  lists  the  three  other  parameters  -  bandwidth,  delivery  method,  and  session  type.  The 
Y-axis  lists  the  average  delay  in  seconds  for  a  message  to  travel  between  two  nodes.  The 
plot  lines  are  the  same  as  those  in  the  baseline  graphs.  An  example  of  an  observation  is 
that  as  the  bandwidth  increased,  the  average  delays  for  whiteboard  decreased  more 
significantly  than  did  the  delays  for  video/audio. 


C.  BASELINE  RUNS 

Twelve  baseline  graphs  which  compare  average  delays  across  all  combinations  of 
bandwidth  and  network  delivery  methods  are  presented  in  Figures  5-3,  5-4,  5-5,  and  5-6. 
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As  mentioned  previously  in  Chapter  V,  the  nine  node  runs  using  128  kbps  and  Unicast 
delivery  were  so  bandwidth  limited  in  the  whiteboard  session  types  that  several  nodes  did 
not  receive  audio,  video  or  whiteboard  messages.  All  average  delays  at  or  above  70 
seconds  in  Figure  5-3  c  reflect  this  occurrence. 

Interpretations  from  Figures  5-3,  5-4,  5-5  and  5-6: 

•  Average  delays  are  reduced  as  bandwidth  is  increased  fi'om  128  kbps  to  384 
kbps. 

•  Multicast  delivery  reduces  the  amount  of  delay.  This  is  more  noticeable  in  the 
nine  node  runs.  Multicast  enables  a  node  to  send  out  one  copy  of  a  message 
instead  of  tying  up  all  the  bandwidth  to  send  out  eight  copies.  It  is  also  faster 
to  send  out  one  message  vice  eight,  so  the  time  saved  sending  messages  can  be 
used  to  receive  messages. 

•  In  Figure  5-3c,  the  plot  line  for  “9  node”  shows  a  slight  decrease  in  average 
delays  for  the  most  stressing  collaboration  session  combination:  whiteboard 
with  high  fi'ame  rate  video  and  high  rate  audio.  Since  only  one  node  is  sending 
out  whiteboard  pictures  to  all  the  other  nodes  this  particular  node  basically 
became  stalled  at  128  kbps  trying  to  send  out  the  pictures.  The  other  nodes 
did  not  have  their  bandwidth  tied  up  receiving  a  whiteboard  picture,  so  they 
were  receiving  and  sending  video  and  audio  messages  with  less  delays.  In 
other  words,  the  collaboration  went  on  despite  the  problems  encountered  by 
one  node. 

•  Figures  5-3c,  5-4c,  5-5c,  and  5-6c  show  a  “dip”  in  the  average  delay  for  the 
session  type  “Whiteboard  with  video  at  4  fps  and  audio  at  14.4  kbps  rate.” 
The  messages  for  this  session  type  requires  34,  676  bits  per  second,  less  than 
most  of  the  other  whiteboard  session  t5q)es  listed  in  Table  5-1.  The  messages 
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in  that  session  type  can  be  sent  out  faster  and  received  faster  which  results  in 
lower  delays.  The  whiteboard  picture  was  held  at  a  constant  size  of  572,810 
bits  across  all  whiteboard  session  types. 


Collaboration  Session  Type 

1 

Total  AudioA^ideo 
Bits 

Wb  +  Audio  (14.4  kbps) 

14,400 

Wb  +  Audio  (64  kbps) 

64,000 

Wb  +  Video  (4  fps)  +  Audio  (14.4  kbps) 

34,676 

Wb  +  Video  (4  fps)  +  Audio  (64  kbps) 

84,276 

Wb  +  Video  (15  fps)  +  Audio  (14.4  kbps) 

90,435 

Wb+  Video  (15  fps)  +  Audio  (64  kbps) 

140,035 

Table  5-1.  Collaboration  Session  Bit  Totals. 


•  In  addition  to  text  chat  and  audio  conferencing  at  14.4  kbps,  three  other 
collaboration  session  t5^es  show  potential  for  being  viable  combinations  for  a 
three  node  scenario.  The  sessions  are:  video  (4  fps)  with  audio  (14.4  kbps), 
whiteboard  with  audio  (14.4  kbps)  and  whiteboard  with  video  (4  Q)s)  and 
audio  (14.4  kbps).  These  sessions  had  average  delays  near  or  below  the  Vi 
second  measure  of  effectiveness.  These  session  types  also  appeared  to  be 
viable  for  nine  node  scenarios  at  a  higher  bandwidth  of  384  kbps.  These  three 
session  types  were  selected  for  additional  runs  with  parameter  settings  of  2  and 
6  nodes,  and  256  kbps. 

D.  FOCUSED  RUNS 

Several  graph  sets  are  presented  in  this  section  to  enable  comparisons  across  the 
parameter  values  used  in  the  model.  Comparisons  were  conducted  by  number  of  nodes, 
bandwidth,  session  type,  and  delivery  mode. 
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1.  Number  of  Nodes  Comparison. 


Six  graphs  are  presented  in  Figures  5-7  and  5-8,  showing  Unicast  delivery  and 
Multicast  delivery.  Three  bandwidths  are  represented:  128  kbps,  256  kbps,  and  384  kbps 
and  four  node  sizes;  2,  3,  6,  and  9. 

Interpretations  of  Figures  5-7  and  5-8; 

•  A  bandwidth  of  384  kbps  with  Multicast  delivery  enables  two  to  nine  nodes  to 
successfully  engage  in  all  three  collaboration  session  types. 

•  In  a  low  bandwidth  environment,  whiteboard  with  audio  at  14.4  kbps  or  video 
at  4  §)s  with  audio  at  14.4  kbps  can  be  used  for  sessions  with  two  or  three 
nodes. 

•  Whiteboard  delay  times  are  more  constant  across  all  bandwidths  in  Multicast 
delivery  mode  than  in  Unicast  mode.  The  sending  node  sends  one  copy  of  the 
whiteboard  picture  in  Multicast  mode  and  the  network  is  responsible  for 
delivery  to  the  other  nodes.  In  many  cases  the  delivery  will  appear  to  be 
“simultaneous”  at  all  nodes,  with  small  delays  occurring  that  are  very  close  in 
duration.  Under  Unicast  mode,  the  sending  node  is  limited  by  its  bandwidth 
and  is  generally  reduced  to  sending  the  pictures  to  the  other  nodes  in  series,  so 
the  last  node  on  the  distribution  list  will  experience  longer  delays  than  the  first 
node  on  the  list. 

•  In  a  two  node  scenario,  no  significant  difference  in  message  delays  was  shown 
between  Unicast  and  Multicast  delivery  methods.  In  each  method,  a  node  is 
only  sending  one  copy  of  a  message.  There  are  no  advantages  gained  by 
employing  Multicast  delivery  in  a  point  to  point  communications  scenario. 
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2.  Bandwidth  Comparison 

Three  graphs  are  presented  in  Figure  5-9  which  show,  as  expected,  that  a  higher 
bandwidth  reduces  delays  and  enables  the  use  of  collaboration  tools  among  a  larger 
number  of  participants. 

3.  Session  Type  Comparison 

Interpretations  for  the  graphs  of  three  collaboration  session  types  in  Figure  5-10, 
are  as  follows: 

•  Multicast  delivery  significantly  reduced  the  amount  of  delay  in  the  largest 
session  (in  terms  of  bit  size):  nine  nodes  using  whiteboard  with  video  at  4  Q)s 
and  audio  at  14.4  kbps,  but  it  was  not  enough  to  get  the  delays  below  the 
acceptable  level  of  Vi  second.  In  general.  Multicast  delivery  reduces  the 
bandwidth  needed  for  one  transmission  by  a  node  intended  to  reach  many 
destinations.  But  Multicast  delivery  does  not  reduce  the  bandwidth  required  at 
the  node  to  accept  many  streams  of  audio  and  video  fi-om  other  collaborating 
nodes.  The  limit  on  the  number  of  session  participants  is  constrained  by  the 
bandwidth  at  a  node. 

•  Whiteboard  delays  were  greater  than  audio  and  video  delays  in  Figure  5-lOb 
and  less  than  audio  and  video  delays  in  Figure  5- 10c.  The  whiteboard  picture 
consisting  of  572,810  bits,  was  large,  even  when  compared  to  the  maximum  of 
eight  audio  messages  that  one  node  sent  out  (115,200  bits)  and  received  in 
(1 15,200  bits)  for  a  total  of  230,400  bits  in  the  nine  node  scenario.  All  these 
bits  were  competing  for  bandwidth  with  the  whiteboard  at  the  node  so  the 
whiteboard  took  slighter  longer  to  receive  than  115,200  bits.  However,  in 
Figure  5- 10c,  the  maximum  combination  of  eight  audio  and  video  streams 
almost  doubled  to  277,408  bits  and,  the  whiteboard  was  now  competing  with 
incoming  and  outgoing  streams  at  the  node  totaling  554,816  bits.  The 
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whiteboard  delay  did  increase  but  did  not  double  as  did  the  delays  for  the  audio 
and  video  messages. 

4.  Delivery  Method  Comparison 

Figure  5-11  presents  the  two  delivery  methods  of  Unicast  and  Multicast.  As 
expected,  there  were  lower  delays  overall  when  Multicast  delivery  was  implemented. 

E.  SPECIAL  RUNS 

Two  special  runs  were  conducted;  one  to  simulate  a  point-to-point  Line  of  Sight 
scenario  that  is  common  between  two  ships  and  another  run  to  compare  two  locations  of  a 
multicast  router. 

1.  Point-to-Point  Communications 

The  results  shown  in  Figure  5-12  are  similar  to  those  of  the  two  node  scenario 
results  presented  earlier. 

•  Multicast  Delivery  does  not  reduce  delays  and  does  not  offer  any  improvement 
over  Unicast  delivery. 

•  A  bandwidth  of  128  kbps  is  still  slightly  limiting  in  conducting  collaboration 
sessions  within  the  Vt.  second  acceptable  delay.  In  general,  a  bandwidth  of  256 
kbps  enables  all  three  types  of  collaboration  sessions  to  occur. 

•  Whiteboard  delivery  delays  are  greatly  reduced  when  bandwidth  is  increased, 
as  expected. 
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2.  Multicast  Router  Location 

Delays  were  added  to  the  three  node  scenario  to  simulate  processing  at  the  router 
and  propagation  times  up  to  and  down  from  a  geostationary  satellite.  The  satellite-based 
multicast  router  generated  the  only  viable  collaboration  sessions  -  whiteboard  with  14.4 
kbps  audio  at  256  kbps  and  384  kbps  bandwidths,  that  were  within  the  Vi  second 
acceptable  delay.  No  sessions  at  128  kbps  via  the  satellite-based  router  were  viable.  The 
additional  round-trip  required  for  messages  to  travel  to  the  shore-based  multicast  router 
increased  delays  across  all  session  types  and  bandwidths  -  no  sessions  were  within 
acceptable  delay  range. 


F.  SUMMARY 

Table  5-2  provides  a  summary  of  the  main  results  of  the  model  runs.  The  columns  list 
combinations  of  Delivery  method  with  bandwidth  sizes  and  the  rows  list  the  number  of 
nodes.  In  each  intersection  of  row  and  column,  there  are  three  letters  which  represent  the 
collaboration  session  types.  The  first  letter  position  from  the  left,  represents  the  video  at  4 
^s  with  audio  at  14.4  kbps  session  type,  the  second  letter  position,  indicates  whiteboard 
with  audio  at  14.4  kbps,  and  the  third  letter  is  the  whiteboard  with  video  at  4  fps  and 
audio  at  14.4  kbps.  The  use  of  the  letter  “Y”  indicates  that  the  collaboration  session  for 
the  combination  of  delivery  method  and  bandwidth  for  a  particular  number  of  nodes 
executed  with  messages  arriving  within  the  second  timeframe  for  an  acceptable  session. 
An  entry  of  “N”  indicates  that  the  collaboration  session  type  for  the  particular  column/row 
combination  did  not  meet  the  14  second  criteria  for  message  arrivals.  As  an  example,  the 
intersection  of  Unicast,  128  kbps  with  3  nodes  is  “NNN”  which  indicates  that  message 
arrivals  for  aU  three  session  types  were  not  below  the  14  second  criteria. 
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Uiicast,  128  kbps 

Unicast,  256  kbps 

Unicast,  384  kbps 

Multicast,  128  kbps 

Multicast,  256  kbps 

Multicast,  384 14)ps 

2  nodes 

YNN 

YYY 

YYY 

YNN 

YYY 

YYY 

3  nodes 

NNN 

YYN 

YYY 

NNN 

YYY 

YYY 

6  nodes 

NNN 

NNN 

NNN 

NNN 

YYN 

YYY 

9  nodes 

NNN 

NNN 

NNN 

NNN 

NYN 

NYN 

1st  Letter  =  video  (4  fps)  +  audo  (14.4  kbps) 

2nd  Letter  =  vttiteboard  +  audio  (14.4  kbps) 

3rd  Letter  =  whiteboard  +  video  (4  fps)  +  audo  (14.4  kbps) 

Table  5-2.  Summary  of  Results. 


The  results  presented  in  Table  5-2  show  that  at  128  kbps,  only  two  nodes  can  have 
a  video  and  audio  collaboration  session.  At  256  kbps,  two  nodes  can  perform  all  three 
session  types.  At  256  kbps  bandwidth,  the  advantages  of  Multicast  delivery  over  Unicast 
also  becomes  apparent  as  more  nodes  can  execute  more  session  types.  Three  nodes  can 
execute  an  additional  session  type  under  Multicast  than  could  be  executed  under  Unicast. 
Sbc  nodes  can  execute  two  collaboration  sessions  under  Multicast  that  could  not  be 
executed  under  a  Unicast  with  256  kbps  combination. 

Multicast  with  384  kbps,  is  the  combination  with  the  most  options  as  the  two, 
three,  and  six  node  scenarios  could  execute  all  three  session  types.  The  nine  node  scenario 
could  execute  the  whiteboard  with  audio  at  14.4  kbps,  and  it  was  very  close  for  the  other 
two  session  types  as  both  averages  were  just  over  the  0.5  second  threshold:  0.5135  second 
delay  for  the  video  (4fps)  and  audio  (14.4  kbps)  session  and  0.5565  second  for  the 
whiteboard  with  video  (4  fps)  and  audio  (14.4  kbps). 

A  high-level  view  of  a  network  was  built  and  simulated  in  an  effort  to  gain  insight 
into  the  use  of  collaboration  tools  and  using  only  four  general  parameters,  results  were 
obtained  that  seemed  intuitively  obvious.  The  level  of  detail  inserted  into  the  models  is 
only  limited  by  the  expertise  of  the  model  builder.  A  more  detailed  look  at  several  aspects 
of  collaborative  planning  at  sea  and  between  ship  and  shore  can  certainly  be  built  and 
executed  within  a  reasonable  timeframe. 
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Unicast,  1 28  kbps  Unicast,  1 28  kbps 


(spuoaas)  Aeiaa  aSeiaAV 


Figure  5-3.  Unicast  with  128  kbps. 
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Figure  5-8.  Number  of  Nodes  (Multicast). 
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Multicast 


Figure  5-1 1 .  Delivery  Comparison. 


Video  and  Audio 
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Figure  5-12.  Point-to-Point. 


VI.  CONCLUSIONS 


How  much  bandwidth  does  an  amphibious  ship  need  in  order  to  perform 
collaborative  planning?  The  goal  of  this  thesis  was  to  provide  some  insight  into  this 
question  through  the  use  of  a  high-level  simulation  model  built  using  a  commercial  off-the- 
shelf  product  called  Extend.  Over  170  model  runs  were  executed  with  various 
combinations  of  the  three  collaboration  tool  types,  the  amount  of  bandwidth,  the  number 
of  planners  involved  in  a  planning  session,  and  the  type  of  network  delivery  method  used. 
The  results  of  these  runs  are  presented  from  three  different  aspects,  by  required 
collaboration  capabilities,  by  bandwidth,  or  by  the  number  of  other  planners  that  can  be 
involved,  as  follows: 

•  Minimum  collaboration  capabilty  required  by  the  ship.  If,  at  a  minimum,  a  ship 
must  be  able  to  conduct  a  video  and  audio  session  with  one  other  ship,  than  at 
least  128  kbps  must  be  available  to  each  ship.  To  conduct  a  whiteboard  with  audio 
session,  at  least  256  kbps  must  be  available.  Whiteboard  with  video  and  audio 
requires  384  kbps. 

•  Bandwidth  is  limited.  If  a  ship  only  has  128  kbps  available,  then  the  ship  will  only 
be  able  to  conduct  a  video  and  audio  session  with  one  other  ship.  At  256  kbps,  a 
ship  can  collaborate  via  a  video  and  audio  session  or  a  whiteboard  with  audio 
session  with  up  to  two  other  sites.  At  384  kbps,  using  multicast  delivery,  a  ship 
will  be  able  to  engage  up  to  eight  other  sites  in  a  whiteboard  with  audio  session. 

•  Number  of  planners  required  in  a  collaboration  session.  To  collaborate  with  one 
other  planner  a  ship  requires  at  least  128  kbps  and  a  session  with  two  other 
planners,  at  least  256  kbps.  To  collaborate  with  five  to  eight  other  planners,  at 
least  384  kbps  must  be  available  at  the  ship  and  multicast  network  delivery  must  be 
used  to  ease  the  bandwidth  congestion  at  the  ship. 
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To  ensure  flexibility  and  adaptability  in  any  planning  situation  a  ship  may  be 
engaged  in,  an  optimum  mix  might  be  to  provide  at  least  256  kbps  bandwidth  and  use 
multicast  network  delivery,  so  the  ship  can  access  some  combination  of  the  three 
collaboration  capabilities  provided  by  the  tools,  with  up  to  five  planning  counterparts. 
Without  multicast  delivery,  at  least  384  kbps  will  be  required  for  three  ships  to  engage  in  a 
collaborative  planning. 

The  models  in  this  thesis  focused  only  on  the  bandwidth  availability  at  the  ship 
level  and  did  not  model  all  aspects  of  network  communications  and  the  delays  caused  by 
network  congestion,  the  routing  protocols  used  or  limitations  imposed  by  satellite 
capacities  and  access  allocations.  Many  fijture  studies  are  possible  which  focus  on  these 
various  delays  and  assess  their  impact  on  the  use  of  collaboration  tools. 

In  amphibious  planning,  the  rapid  response  planning  process  is  six  hours. 
Additional  future  studies  could  examine  how  the  use  of  collaboration  tools  might  affect 
planning  timelines  or  the  sequence  of  planning  events. 


APPENDIX  A:  DH  COE  CRITERIA  FOR  COLLABORATION  SOFTWARE 


The  Defense  Information  Infrastructure  Common  Operating  Environment 
Multimedia/Collaborative  Services  Technical  Working  Group  (DH  COE  MCSTWG)  has 
been  established  as  part  of  the  DH  COE  and  is  tasked  to  define  a  common  core  of  required 
capabilities  for  collaboration  software  services.  This  appendix  contains  the  requirements 
identified  for  audio,  video,  and  whiteboard  applications. 

1.  Audio  conferencing  software  shaU  provide: 

-  Point  to  point  and  multipoint,  multi-user  conferencing 

-  Multiple  operating  modes  (e.g.,  support  for  interactive  conference  (people  sending 
and  receiwng  from  multiple  sites),  support  for  one-way  conferences  (one  site 
sending,  all  other  sites  receiving) 

-  Ability  to  add/remove  users  during  a  conference 

-  Support  for  speaker/microphone  control. 

-  Push  to  talk 

-  Audio  mute  on  send  and  receive,  near  and  far 

-  Support  for  private  side  conferences  (whisper  mode) 

-  An  adjustable  bandwidth  control 

-  Adaptation  to  lowest  common  audio  denominator  for  lower  bandwidth  participants 
(e  g.,  automatic  protocol  negotiation) 

-  Support  down  to  2400  baud  per  second  and  support  up  to  8  Khz  audio. 

-  Support  for  secure  audio  conference  channel 

-  Ability  to  save  and  recall  audio  conference  (e  g.,  in  ADPCM,  MPEG  formats) 

-  Gateway  to  other  audio  conferencing  formats 
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-  Support  for  GSM,  LPC-10  (2.4),  CELP,  and  G.700  series  interoperability 
standards 

-  Support  for  full  duplex 

2.  Video  conferencing  software  shall  provide: 

Point  to  point  and  multipoint,  multi-user  conferencing 

-  Multiple  operating  modes  (e.g.,  support  for  interactive  conference  (people  sending 
and  receiving  from  multiple  sites),  support  for  one-way  conferences  (one  site 
sending,  all  other  sites  receiving) 

-  Ability  to  add/remove  users  during  a  conference 

-  An  adjustable  frame  rate 

-  An  adjustable  compression  ratio 

-  An  adjustable  image  size 

-  Adaptation  to  lowest  common  audio  and  video  denominator  for  lower  bandwidth 
participants 

-  Support  for  rate  governing 

-  Support  for  secure  video  conference  channel 

-  Ability  to  save  and  recall  video  conference  (MPEG) 

-  Frame  grab  video  image  and  save  to  file  (e.g.,  JPEG,  Postscript,  GIF) 

-  Gateway  to  other  conferencing  formats 

-  Support  for  H.320  series  interoperability  standards 
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3.  Whiteboard  tools  shall  provide: 

-  Support  for  multiple  users  annotating  simultaneously  (including  individualized 
cursors  that  are  visually  distinct  and  identify  user) 

-  Ability  to  import  image  formats  as  whiteboard  background,  including  screen 
capture  (window,  entire  screen,  user  defined  area),  NITF,  JPEG,  GIF,  and 
Postscript 

-  Support  for  8-bit  and  24-bit  imports 

-  Ability  to  export  image  background  and  annotations  to  JPEG  (burned  in 
annotations),  NITF  (nondestructive  annotations).  Postscript  (burned  in 
annotations),  TIFF  (burned  in  annotations),  GIF  (burned  in  annotations) 

-  Gesturing/pointing  tool 

-  Text,  line,  arrow,  rectangle,  circle,  oval,  polygon,  fi-ee  draw  annotation  tools,  multi¬ 
color  annotations 

-  Ability  to  import  custom  symbols  for  aimotations 

-  Geopositioning  of  symbols  on  imported  maps 

-  Attributed  annotations  (e.g.,  user,  date,  comments)  and  the  ability  to  store  and 
retrieve  meta  data  with  annotations 

-  Ability  to  overlay  vectors  (e.g.,  VPF,  CGM)  on  raster  backgrounds. 

-  Nondestructive  whiteboard  annotations 

-  Ability  to  add/remove  users  during  session 

-  Persistence  of  whiteboards  for  on-going  collaborations  (e.g.,  ability  to  save  and 
recall  state) 

-  Support  for  Secure  whiteboard  sessions 

-  Support  for  T.  126  series  interoperability  standards 

-  Plug-in  capability  to  expand  functionality 
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APPENDIX  B:  COMPARISON  OF  COLLABORATIVE  PRODUCTS 


The  Defense  Information  Infrastructure  Common  Operating  Environment 
Multimedia/Collaborative  Services  Technical  Working  Group  (DU  COE  MCSTWG)  with 
assistance  from  MITRE,  conducted  an  evaluation  of  audio,  video,  and  whiteboard 
commercial  off-the-shelf  products  in  1997.  The  results  are  presented  in  the  following 
matrixes. 
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relocate 
annotations 

Yes  except  no 
arrow,  no 
polygon 

Yes 

1  Yes 

Microsoft 

NetMeetinq 

o 

z 

Wln95.NT4.0 

(A 

Yes,  \4a  Peer  to 
Peer  or  MCU 

Captured 
Window, 
Selected 
Screen  Area 

None 

Yes 

Yes  except  no 
arrow,  no 
polygon 

Yes 

1  Yes 

LBLWB 

1.59  ! 

Yes  1 

Yes 

o 

z 

sax 

Yes,  via 
Multicast 

Postscript 

None 

Yes 

Yes,  excpet  no 
circle  or 
polygon 

DES  encryption 

o 

z 

Intel  Business  Video 
Conferencing  with 
ProShare 
Technology 

q 

o 

z 

o 

z 

Win95,  NT4.0 
(Planned) 

Yes 

Yes,  via  Peer  to 
Peer 

Captured  Window, 
Selected  Screen 
Area 

None 

Yes 

Yes  except  no  arrow 
no  polygon 

Yes 

1  Yes 

Habanero 

Whiteboard 

1.0b4  I 

Yes  1 

Yes  I 

Win95.  NT4.0 

(A 

Yes,  via 
Conference 
Server 

JPEG.  GIF 

None 

Yes 

Yes,  no  arrow, 
cirice,  polygon 

1  Yes 

DataBeam 

FarSite 

o 

cd 

o 

z 

o 

z 

Win95.  NT4.0 

lA 

Yes,  via  Peer  to 
Peer  or  MCU 

Captured 
Window, 
Selected  Screen 
Area,  JPEG 

TIFF.  JPEG 

Yes 

Yes  except  no 
arrow,  no 
polygon 

Yes 

1  Yes 

Paradise  Simplicity 
H.323 

q 

Yes  (Fall  97) 

Yes  (Fall  97)  I 

Yes  (Fall  97) 

1 

Yes,  via  Multicast 
or  MCU  (Fall  97) 

Captured  Window, 
Selected  Screen 
Area,  JPEG, 
Raster,  NITF  2.0 
(but  uncompressed 
and  no  metadata) 

JPEG.  TIFF.  GIF 

Yes,  but  can't 
select  or  relocate 
annotations 

Yes  except  no 
arrow,  no  polygon 

o 

z 

1  Yes 

Tool  Version  I 

Solaris  2.5.1  I 

X 

3 

CL 

X 

z 

IP-based 

Multiuser  conferencing 
(>2  users) 

Import  backdrop  formats 
(8  and  24-bit) 

-  Captured  window 

-  Selected  screen  area 

-  JPEG  image 
•  Raster  image 

-  NITF  image  (bring  in 
meta  data) 

-  GIF  image 
r^Postscrlpt  image 

izxpon  oacKorop  image 

and  burned  in 

annotations 

-JPEG 

-TIFF 

-GIF 

-  Postscript 

-  NITF  (annotations  not 
burned  in  with  meta 
data) 

Nondestructive 
annotations  during 
session 

Annotation  tools  for  text, 
line,  arrow,  rectangle, 
circle,  oval,  polygon, 
freed  raw 

Conference  participation 
control  (private,  no 
eavesdropping)  (Not 
security) 

iGesturing/pointing  tool 

D 

B 

B 

B 

B 

eo 

a> 

_ 

11 

CM 

gl 
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Shared  Whiteboards 


WhitePines 

CUSeeMe 

No,  removal  of  self 
only 

1 

(A 

■o 

V 

c 

c 

n 

Q. 

O 

z 

Captured 
Desktop,  TIFF, 
FST,  BMP.  DIB. 
PCX,  TGA,  PCT, 
EPS.  WPG.  WMF, 
DCX 

e  S  2 

o  >< 

|g|8 

!o‘g<p- 

“•0-& 

o 

z 

No 

o 

z 

No 

No 

O 

Z 

No 

_ Yes _ 1 

© 

« 

1  Select  and  delete  | 

1  1 

1 

VocalTec  ICP 

No,  removal 
of  self  only 

■ 

o 

z 

MS  Office 
docs  and  any 
OLE  senrer 
object 

No 

Yes,  if  from 
an  OLE  server 

No 

No 

o 

z 

No 

1  Yes 

o 

Z 

o 

z 

1  Yes 

1  Yes 

1 

Sun  ShowMe 

Yes 

Yes 

c  -6 
o  ©  © 

s  -  s 

« 

No,  planned 

© 

c 

o 

Z 

Sun  Raster 

No 

No 

No 

No 

1  No 

Yes  -  bottom 
layer 

Yes 

1  Yes 

1  Yes 

1  Yes 

1  No 

- 

PictureTel 

LiveLAN 

*5 

i! 

s.S 

o 

Z 

Yes 

Yes 

No.  planned 

WHT 

WHT 

_ _ 

No 

No 

No 

No 

Yes 

Yes 

1  Yes 

1  Yes 

1  Yes 

1  Yes 

1  Yes 

1 

Netscape 

Conference 

1 

1 

Captured 
Desktop,  TIFF, 
BMP 

BMP 

ssA 

o 

z 

No 

No 

No 

No 

No 

No 

No 

1  Yes 

1  Yes 

Yes 

1  Yes 

1 

1 

o  a> 
u  S 

S  ® 
^  z 

E  1 
£  “5 
-  w 
o 
z 

lA 

5 

1- 

X 

$ 

© 

o 

Z 

No 

No 

No 

No 

Yes 

Yes 

Yes 

Yes 

© 

Yes 

1  Yes 

LBLWB 

o 

II 
£  « 
-  » 
o 
z 

1 

No 

No 

No 

o 

z 

No 

o 

z 

o 

z 

o 

z 

1  Yes 

o 

z 

1 

Intel  Business  Video 
Conferencing  with 
ProShare 
Technology 

© 

u> 

o 

"w  >- 

E  ® 
£ 

o‘ 

z 

© 

>- 

w 

TO 

© 

c 

c 

» 

a 

5 

5 

5 

w 

o 

>- 

o 

z 

No 

No 

No 

No 

© 

Yes 

1  Yes 

1  Yes 

1  Yes 

Yes 

1  Yes 

1 

Habanero 

Whiteboard 

*& 

II 

s  © 

o 

Z 

<A 

o 

z 

© 

c 

O 

Z 

O 

z 

w 

© 

>- 

o 

z 

No 

No 

o 

z 

Whiteboard  is  a 
demo  only 

1  No 

No 

1  No 

1  Yes 

i 

1  delete 

1  No 

1 

DataBeam 

FarSite 

II 
£  © 
-  © 
o 
z 

(A 

w 

c 

c 

© 

Q 

6 

z 

Captured 
Desktop,  TIFF. 
FST,  BMP,  DIB. 
PCX,  TGA.  PCT, 
EPS.  WPG. 
WMF.  DCX 

FST,  BMP,  DIB. 
PCX,  TGA.  PCT. 
EPS,  WPG, 
WMF,  DCX 

S0A 

No 

No 

No 

No 

No 

±: 

ja 

(D 

1  No 

No 

Yes 

1  Yes 

1 

S 

1  delete 

1  Yes 

1 

Paradise  Simplicity 
H.323 

*© 

(A 

is 

£ 

d" 

z 

CA 

© 

>“ 

1  S 
t.i 

O  c 

u  ® 

o  3 
Z  -3 

•© 

© 

c 

c 

n 

a 

o" 

z 

< 

§ 

0.* 

5 

CD 

uT 

u. 

1- 

Ql 

CO 

No 

No 

No 

No 

No 

No 

M 

Yes 

1  Yes 

1  Yes 

1 

£ 

© 

^  1 
"S 

i  «= 

p  s 

C  ID 
©  (A 
O  ® 

c  w 

ii  S’ 

Off*© 

A 

£  « 
©  3 

3  g.i 

Z  ©  lA 

c 

© 

© 

il « 

l|  g 

•£  -S  © 
£  .-K  5 

<0 

CM 

H 

a. 

o 

s 

u 

A 

a.= 

M  © 

si 

Q. 

2 

s 

1 

jS 

©  i 

si 

» 

c 

o 

1 

c 

c 

© 

o 

o 

”3 

© 

c 

oi 

3 

o 

© 

c 

o 

ts 

c 

3 

u. 

Import  custom  symbols 
for  annotations 

Overlay  vector  graphics 
(VPF,  CGM)  on  raster 
backgrounds 

symbols  on  imported 
maps 

Attributed  annotations: 
user,  date,  comments 

s 

3 

© 

JA 

I 

.c 

u 

1 

s 

Can  lock  whiteboard 
contents 

£ 

£ 

.S’ 

IE 

Oi 

X 

1  Filled  rectangle  option 

1  Filled  circle/oval  option 

© 

© 

£ 

LiJ 

* 

15 

n 

a 

n 

o 

E 

1 

1 

- 

U) 

(0 

5 

CO 

0> 

1 

m 

L3 

L3 

0 

CO 

<o 
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Pag©  2 


Shared  Whiteboards 


WhitePines 

CUSeeMe 

Yes  -  but  only 
from  one  page  to 
another  within  the 
whiteboard;  not 
within  a  page  and 
not  to  outside 
applications 

Yes 

- - 

_ _ 

Yes 

Uses  Databeam's 
FarSite  for  the 
Whiteboard 

VocalTec  ICP 

No,  but  can 
copy  and 
paste  OLE 
objects  onto 
and  within 
whiteboard 

o 

z 

_ _ 

No 

-3 

Sun  ShowMe 

No 

No 

Yes 

0 

Z 

Yes 

Sun  hasT.120 
product  in  the 
works 

- 

PictureTel 

LiveLAN 

Yes  -  both  from 
within  a  page  and 
from  one  page  to 
another  within  the 
whiteboard  as 
well  as  to  outside 
applications 

Yes 

v> 

Yes 

Yes 

Uses  same  core 
software  as  MS 
NetMeeting  for 
the  Whiteboard; 
LiveLAN  3.5  will 
run  under  NT4.0 
and  will  use  the 
MS  NetMeeting 
application  that 
comes  bundled 
with  NT4.0  for  its 
data  conferencing 
tool 

I 

Netscape 

Conference 

Yes  -  can 
select 
annotation 
region  and 
paste  it  as  a 
bitmap;  Can 
also  paste 
text/graphics 
from  other 
applications  as 
bitmaps 

o 

z 

sax 

ON 

Only  two  can 
participate  in  a 
whiteboard 
session 

Original 

Whiteboard 

Software 

o 

Microsoft 

NetMeeting 

Yes  -  both  from 
within  a  page 
and  from  one 
page  to  another 
within  the 
whiteboard  as 
well  as  to 
outside 
applications 

Yes 

S0A 

tfl 

Yes 

Original 

Whiteboard 

Software 

U- 

LBLWB 

Yes 

Yes 

V) 

Yes 

tu 

Intel  Business  Video 
Conferencing  with 
ProShare 
Technology 

Yes  -  both  from 
within  a  page  and 
from  one  page  to 
another  within  the 
whiteboard  as  well 
as  to  outside 
applications 

lA 

S9A 

saA 

Yes 

Uses  MS 

NetMeeting  for  the 
Whiteboard 

o 

Habanero 

Whiteboard 

No 

to 

o 

z 

o 

z 

Yes 

o 

DataBeam 

FarSite 

Yes  -  but  only 
from  one  page  to 
another  within 
the  whiteboard; 
not  within  a  page 
and  not  to 
outside 
applications 

(0 

saA 

lA 

Yes 

Original 

Whiteboard 

Software 

CQ 

Paradise  SirDplicity 
H.323 

No 

o 

z 

o 

z 

o 

z 

Yes 

Original 

Whiteboard 

Software 

< 

Copy  and  paste 
annotations 

J2 

c 

1 

o 

u 

d> 

cn 

(0 

a 

S 

3 

s 

Conference  participants 
identified 

1 

- 

in 

CO 

<D|h>| 

co|co| 

_ ^ 

CO 
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Paae  3 


APPENDIX  C:  BANDWIDTH  REQUIREMENTS  MATRIX 


The  following  matrix  was  put  together  to  consolidate  bandwidth  requirements  for 
collaborative  planning  or  for  collaboration  tools  encountered  by  the  author  during  her 
research.  The  sources  are  listed  in  the  first  colunm. 
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Bandwidth  Requirements. 


APPENDIX  D:  EXTEND  MODEL  STRUCTURES 


The  model  structures  are  presented  as  printouts  obtained  from  the  Extend  displays. 
Many  levels  of  hierarchy  can  be  built  into  a  model  and  several  pages  are  used  to  shown 
each  level  of  the  node  and  router  structures,  starting  at  the  top  levels  and  working  down 
into  the  details  of  specific  blocks. 

The  node  structure  shown  is  that  of  Node  1  which  sends  out  audio,  video,  and 
whiteboard  messages  with  annbtations.  This  basic  structure  was  copied  to  represent  the 
number  of  nodes  in  the  scenario,  from  two  to  nine. 

The  router  structure  shown  is  that  of  the  Multicast  router  with  the  “replicator” 
block.  A  Unicast  router  is  achieved  by  disconnecting  the  replicator  block  in  the  model. 
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Node  Structure 
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Transmit/Receive  and  Sort  Block 


85 


Node  structure.MOX  - 


Node  structure.MOX  - 


ConTOut 


[1221]  four  type  sorter 
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Router:  Multicast  mode  has  Replicator  block. 

Unicast  mode  does  not  have  Replicator  block. 
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Router  Structure.MOX  • 


Replicator:  Determines  which  node  sent  the  message  then  makes  copies  for  all  destinations. 


Make  Copies:  For  a  message  from  a  specific  node  (in  this  case  Node  1),  replicate  for  distribution 

to  other  nodes  in  the  subnet  (node  2  and  3),  and  to  other  Routers  (Routers  20  and  30). 


Router  Structure.MOX  • 


APPENDIX  E:  EXTEND  MODEL  RUNS 


The  following  matrices  show  the  various  combinations  of  parameters  that  were 
used  and  the  resulting  model  runs  that  were  executed. 
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Baseline  Runs  -  3  nodes 


Run  Number  |  session  type 


111  text  chat  -  high 

112  audio  -  14.4  kbps 

113  audio -64  kbps 


eo  - 
eo- 


#  nodes  Delivery  I  Bandwidth 


unicast 

unicast 


unicast 


118 

wb  +  14.4  kbps  audio 

2 

119 

wb  +  64  kbps  audio 

2 

120 

wb  +  4  fps  video  + 14.4  kbps  audio 

2 

121 

wb  +  4  fps  video  +  64  kbps  audio 

122 

wb  +  1 5  fps  video  +  14.4  audio 

123 

wb  +  15  fps  video  +  64  kbps  audio 

2 

311 

text  chat  -  high 

3 

312 

audio  - 14.4  kbps 

3 

unicast 

unicast 

unicast 

unicast 

unicast 


unicast 


unicast 


unicast 


384  kbps 
384  kbps 


384  kbps 
384  kbps 


384  kbps 


384  kbps 


384  kbps 


313 

audio  -  64  kbps 

314 

video  -  low  4  fps  + 14.4  kbps  audio 

video  -  low  4  fps  +  64  kbps  audio 

% 

video  -  high  15  fps  +  14.4  kbps  audio 

317 

video  -  high  15  fps  +  64  kbps  audio 

3 

318 

wb  + 14.4  kbps  audio 

3 

319 

wb  +  64  kbps  audio 

3 

320 

wb  +  4  fps  video  +  14.4  kbps  audio 

3 

321 

wb  +  4  fps  video  +  64  kbps  audio 

3 

322 

wb  + 1 5  fps  video  +  14.4  audio 

3 

323 

wb  +  1 5  f^  video  +  64  kbps  audio 

3 

multicast  ^384  kbps 


multicast  |384  kbps 


multicast  |384  kbps 


384  kbps 


512 

audio  -  14.4  kbps 

3 

513 

audio  -  64  kbps 

3 

video  -  low  4  fps  +  14.4  kbps  audio 

: 

video  -  low  4  fps  +  64  kbps  audio 

unicast 


video  -  high  15  fps  +  14,4  kbps  audio 
video  -  high  1 5  fps  +  64  kbps  audio 
wb  +  14.4  kbps  audio 


519 

wb  +  64  kbps  audio 

520 

wb  +  4  fps  video  +  14.4  kbps  audio 

128 

kbps 

128 

kbps 

128 

kbps 

128 

kbps 

128 

kbps 

ESS 


521 

wb  +  4  fps  video  +  64  kbps  audio 

3 

unicast 

128  kbps 

522 

wb  +  15  fps  video  +  14.4  audio 

3 

unicast 

128  kbps 

523 

wb  + 15  fps  video  +  64  kbps  audio 

3 

unicast 

128  kbps 

711 

text  chat  -  high 

3 

712 

audio  -  14.4  kbps 

3 

713 

audio  -  64  kbps 

714 

video  -  low  4  fps  +  14.4  kbps  audio 

I  video  -  low  4  fps  +  64  kbps  audio 


cas 

cas 


multicast 


128  kbps 


128  kbps 


1128  kbps 


716 

video  -  high  15  fps  + 14.4  kbps  audio 

5 

multicast 

128  kbps 

717 

video  -  high  1 5  fps  +  64  kbps  audio 

5 

multicast 

128  kbps 

wb  +  14.4  kbps  audio _ 

wb  +  64  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 
wb  +  4  fps  video  +  64  kbps  audio 
wb  +  15  fps  video  +  14.4  audio 


wb  +  15  fps  video  +  64  kbps  audio 


multicast 


multicast 


multicast 


multicast 


multicast 


[128  kbps 


1128  kbps 


1128  kbps 
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Baseline  Runs  -  9  Nodes 


audio  ■  1 4.4  kbps 


audio  -  64  kbps 


video  -  low  4  fps  +  14.4  kbps  audio 


video  -  low  4  fps  +  64  kbps  audio 


video  -  high  15  fps  +  14.4  kbps  audio 
video  -  high  15  fps  +  64  kbps  audio 


wb  + 14.4  audio 


wb  -I-  64  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 


wb  +  4  fps  video  +  64  kbps  audio 
Iwb  +  15  fps  video  +  14.4  audio 


wb  +  15  fps  video  +  64  kbps  audio 


|audio-64  kbps 


video  -  low  4  fps  + 14.4  kbps  audio 


video  -  low  4  fps  +  64  kbps  audio 
video  -  high  15  fps  +  14.4  kbps  audio 


video  -  high  15  fps  +  64  kbps  audio 
wb  + 14.4  kbps  audio 


wb  +  64  kbps  audio _ 

wb  +  4  fps  video  +  14.4  kbps  audio 
wb  +  4  fps  video  +  64  kbps  audio 


{text  chat  -  high 


audio  - 14.4  kbps 


[audio  -  64  kbps 


video  -  low  4  fps  +  1 4.4  kbps  audio 


video  -  low  4  fps  +  64  kbps  audio 


video  -  high  15  fps  +  14.4  kbps  audio 
video  -  high  15  fps  +  64  kbps  audio 


618 

wb  +  14.4  audio 

619 

+  64  kbps  audio 

620 

wb  +  4  fps  video  +  14,4  kbps  audio 

wb  +  4  fps  video  +  64  kbps  audio 
wb  +  1 5  fps  video  +  1 4.4  audio 
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multicast 
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multicast  384  kbps 

multicast  384  kbps 

multicast  384  kbps 

multicast  384  kbps 

multicast  384  kbps 

multicast  384  kbps 

3  NODES 


Run  Number  I  session  type 


2  NODES 


I  #  nodes  | Delivery  (Bandwidth 


2 

unicast 

128  kbps 

2 

unicast 

384  kbps 

2 

unicast 

256  kbps 

18 

wb  +  14.4  kbps  audio 

2 

unicast 

128  kbps 

18b 

wb  +  14.4  kbps  audio 

2 

unicast 

384  kbps 

18c 

wb  +  14.4  kbps  audio 
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unicast 
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20 

wb  +  4  fps  video  + 14.4  kbps  audio 

2 

unicast 

128  kbps 

20b 

wb  +  4  fps  video  +  14.4  kbps  audio 

2 

unicast 

384  kbps 

20c 

wb  +  4  fps  video  +  14.4  kbps  audio 

d 

unicast 

unicast 


unicast 


128  kbps 


1384  kbps 


1 256  kbps 
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1115 
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unicast 
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unicast 
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3 
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multicast 
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wb  +  14.4  kbps  audio  _ 
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unicast 


68 

wb  +  14.4  kbps  audio 
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video  -  low  4  fps  + 

14.4  kbps  audio 

9 

multicast 

128  kbps 

video  -  low  4  fps  + 

14.4  kbps  audio 

9 

multicast 

384  kbps 

video  -  low  4  fps  + 

14.4  kbps  audio 

9 

multicast 

256  kbps 

wb  +  14.4  kbps  audio 


wb  +  14.4  kbps  audio 


wb  +  14.4  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 


multicast 


multicast 


multicast 


128  kbps 
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256  kbps 


multicast 
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multicast 

256  kbps 

Special  Runs 


Point  to  Point  Scenario 

Run  Number 

session  type 

#  nodes 

Delivery 

Bandwidth 

unicast 

128  kbps 

unicast 

384  kbps 

video  -  low  4  fps  +  14.4  kbps  audio 
video  -  low  4  fps  +  14.4  kbps  audio 


wb  +  14.4  kbps  audio 
wb  14.4  kbps  audio 
wb  +  14.4  kbps  audio 


wb  +  14.4  kbps  audio 


unicast 

unicast 


unicast 

unicast 

unicast 


unicast 


256  kbps 


64  kbps 


128  kbps 
384  kbps 
256  kbps 


64  kbps 


unicast  128  kbps 


20b 

wb  +  4  fps  video  +  14.4  kbps  audio 

2 

unicast 

384  kbps 

20c 

wb  +  4  fps  video  +  14.4  kbps  audio 

2 

unicast 

256  kbps 

20d 

wb  +  4  fps  video  +  14.4  kbps  audio 

2 

unicast 

64  kbps 

Satellite  as  Multicast  Router 

Run  Number 

session  type 

#  nodes 

Delivery 

Bandwidth 

1023 

video  -  low  4  fps  +  14.4  kbps  audio 

3 

multicast 

128 

1023b 

video  -  low  4  fps  +  14.4  kbps  audio 

3 

multicast 

256 

1024 

video  -  low  4  fps  +  14.4  kbps  audio 

3 

multicast 

384 

1025 

wb  +  14.4  kbps  audio 

3 

multicast 

128 

1025b 

wb  +  14.4  kbps  audio 

3 

multicast 

d 

1026 

wb  +  14.4  kbps  audio 

3 

multicast 

wb  +  4  fps  video  +  14.4  kbps  audio 


wb  +  4  fps  video  +  14.4  kbps  audio 
wb  +  4  fps  video  +  14.4  kbps  audio 


3  multicast 


Satellite  Ashore 


I  video  -  low  4  fps  +  14.4  kbps  audio 


Slmulticast 


wb  +  14.4  kbps  audio 

3 

multicast 

■I 

wb  +  14.4  kbps  audio 

3 

multicast 

wb  +  14.4  kbps  audio 
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multicast 

1032 _ wb  +  4  fps  video  +  14.4  kbps  audio 

1032b  wb  +  4  fps  video  +  14.4  kbps  audio 


1032c  |wb  +  4  fps  video  14.4  kbps  audio 


3  multicast 
3  multicast 


3  multicast 
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APPENDIX  F:  EXTEND  MODEL  RESULTS 


The  following  spreadsheets  contain  the  data  that  was  collected  from  the  Extend 
model  runs.  Additional  rearrangements  were  performed  in  order  to  generate  the  charts 
presented  in  Chapter  V. 
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Special  Runs 


*******  128  kbps 

Video  (4  fps)  +  Audio  (14.4  kbps) 

Avg  Delay 

3  node 

0.784333 

0.715  0.719 


3  node  Audio 
3  node  Video 


0.944  0.829 

0.719  0.558' 


Wb  +  Video  (4  fps)  *  Audio  (14.4  kbps) 
3  node 


3nodeWb 


iQgiggRii 
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*******  256  kbps  _ 


Video  (4  fps)  +  Audio  (14,4  kbps 


3  node 


IEB5II551I 


0.589333  0.738  0.738  0.618  0.52  0.521  0.401 


3  node  Audio 


3  node  Video 


0.618 


0.521  0.401 


3  node  Audio 


3  node  Wb 


Wb  *  Video  (4  fps)  +  Audio  (14.4  kbps; 
3  node 


3  node  Wb 


*******  384  kbps 
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3  node  Audio 


3  node  Video 


Wb  +  Audio  (14.4  kbps 


3  node  Audio 


0.484333  0.5961 


4.716  4.716 
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06^^  0693^  057^ 


0.468  0.347 


0.406  0.493  0.373  0.352 


3.23 


3  node 


3  node  Wb 


0.529667  0.383  0.688  0.615  0.631  0.468  0.393 
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******  128  kbps _ ^ 

Video  (4  fps) »  Audio  (14.4  kbps)  Avg  Dela 


3  node  1.313667 


3  node  Audio 
3  node  Video 


Wb  + Audio  (14.4  kbps) 
3  node  Audio 


3  node  Wb 


Avg  Delay 
1.138' 


9.588 


Wb  +  Video  (4  fps)  *  Audio  (14.4  kbps)  Avg  Delay 
3  node  9.054833 ' 


3nodeWb  9.746 


*******  256  kbps _ 

Video  (4  fps)  +  Audio  (14.4  kbps) 


3  node 


1.044833 


3  node  Audio 
3  node  Video 


*  Audio  (14.4  kbps) 

3  node  Audio _ 


3  node  Wb 


Avg  Delay 
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Wb  Video  (4  fps)  +  Audio  (14.4  kbps)  Avg  Delay 
3  node  7.2851 67 ' 


3nodeWb  5.039 


*******  384  kbps _ 

Video  (4  fps)  +  Audio  (14.4  kbps) 
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3  node  Audio _ 


3  node  Video 
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3  node  Audio 


3  node  Wb 


Avg  Delay 
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3.529 
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1.649 
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1.356 

1.001 
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1.338 
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1.192 
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1.338 

1.338 

1.192 
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5.016 
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7.375 
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